Buffer-copy Question

ForEachInvoiceDelete

Active Member
I heard something new today, and being mr skeptical i wanted to validate.

Buffer-Copy source to target wont cause any IO writes if the source and target are the same.

Please validate/debunk.

- Jase
 

Rob Fitzpatrick

ProgressTalk.com Sponsor
I'm not sure I understand the case you're describing. But offhand I'd say creating a record will cause I/O (BI writes, AI writes, creation of the record in a block, creation of index keys, possible index block split(s)) no matter what. The storage engine doesn't know or care that the source of the field data was a buffer-copy.
 

ForEachInvoiceDelete

Active Member
So to elaborate slightly.

Code:
DEFINE BUFFER bEmployee FOR Employee.

FOR EACH Employee EXCLUSIVE-LOCK.

    FIND bEmployee where bEmployee.UniqueValue = Employee.UniqueValue NO-ERROR.

    BUFFER-COPY bEmployee to Employee.

END.

Now i realize this is pointless, as the source and target for the buffer copy are identical. But will progress still do the I/O operations, or does it know its pointless and do nothing?
 

Rob Fitzpatrick

ProgressTalk.com Sponsor
Fair question I guess, although the business logic is... interesting.

I guess the easiest answer is to run the code and look at _UserIO or ProTop and see for yourself.
 

TheMadDBA

Active Member
OpenEdge optimizes updates by not actually writing the changes to disk/memory if the columns are the same. This is a pretty rare feature for most databases. It has been like this for quite some time.. not sure which version it started in but it has been there for at least a decade or so :)

If you run the code about you will see no updates in promon or in the VSTs.. or write triggers firing.

I have never dug into the internals enough because it just doesn't come up enough but I think this is handled on a per column basis.
 

TomBascom

Curmudgeon
I believe those optimizations came with v9.

Prior to that you could generate tons of useless bi notes with silly code like:

Code:
for each customer exclusive-lock:
end.
 
Top