By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
435,414 Members | 2,919 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 435,414 IT Pros & Developers. It's quick & easy.

update transmogrifies to insert/delete

P: n/a
been ruminating on the question (mostly in a 390/v7 context) of
whether, and if so when, a row update becomes an insert/delete.

i assume that there is a threshold on the number of columns of
the table, or perhaps bytes, being updated where the engine just
decides, screw it, i'll just make a new one.

surfed this group and google, but couldn't find anything.

the context: we have some java folk who like to parametize/
generalize/exersize into what they call Data Access Objects, and
end up looping through a database result set based on column
metadata (thus not having to write any table specific code),
resetting all columns. makes for generatable code, but i for one
don't like it.

seems to be the worst possible performance scenario??
Nov 12 '05 #1
Share this Question
Share on Google+
16 Replies


P: n/a

"robert" <gn*****@rcn.com> wrote in message
news:da**************************@posting.google.c om...
been ruminating on the question (mostly in a 390/v7 context) of
whether, and if so when, a row update becomes an insert/delete.

i assume that there is a threshold on the number of columns of
the table, or perhaps bytes, being updated where the engine just
decides, screw it, i'll just make a new one.

surfed this group and google, but couldn't find anything.

the context: we have some java folk who like to parametize/
generalize/exersize into what they call Data Access Objects, and
end up looping through a database result set based on column
metadata (thus not having to write any table specific code),
resetting all columns. makes for generatable code, but i for one
don't like it.

seems to be the worst possible performance scenario??


I'm a Java developer but I've never used Data Access Objects so I may not be
qualified to comment on this question.

However, I would be quite astonished if "the engine" _EVER_ "just decides,
screw it, I'll just make a new one". (I assume that when you say "the
engine" you mean the DB2 code itself, as opposed to some third party add-on
to DB2.)

Frankly, I've never heard so much as a whisper of a hint of a rumour of a
suggestion that DB2 could transform an SQL Update statement to an Insert
and/or a Delete and I've been working with DB2 in one capacity or another
for 20 years.

As far as I know, an Update is always an Update, a Delete is always a
Delete, and an Insert is always an Insert and none of these can change from
one to the other.

Of course, I *could* be wrong....

Having said that, an *application* which uses DB2 should be able to turn an
update statement into a delete/insert. For instance, if a user submitted a
query like this through an interface that I wrote:
update Employee
set salary = salary * 1.1
where empno = '000010'

I could imagine converting that to:
1) a delete that removed the current row for employee 000010
2) an insert to create a new row for employee 000010 but with a 10% raise in
salary.

Of course, the code to do this would also need a select to determine the
current values of all of the other columns in the original row so that they
could be copied to the new row during the insert.

However, there could easily be important side-issues with respect to related
data. For instance, if the Employee table in the example had dependent
tables, such as Employee_Health_Claims, doing the delete in the Employee
table could cause all rows of Employee_Health_Claims that relate to that
Employee to be deleted if a DELETE CASCADE rule was in effect. (And rows in
tables dependent on Employee_Health_Claims might also be deleted if the
DELETE CASCADE rule was in effect on this foreign keys.)

By the same token, the delete in the Employee table would fail if there was
a DELETE RESTRICT rule between Employee and Employee_Health_Claims. You
would have to consider Referential Integrity issues very carefully if you
chose to convert an Update into a Delete/Insert combination.

After all, you wouldn't want an update in one table to cause all sorts of
data to be deleted just because you thought you might get a slight advantage
by turning one Update into a Delete followed by an Insert.

Since I'm not sure if I really understood the intent of your question, I
don't know if this answers it. If not, perhaps you can clarify what you are
after. Then I - or others on this newsgroup - could try again.

Rhino
Nov 12 '05 #2

P: n/a
I'd beg to differ just a little bit here.
IN DB2 UDB for LUW:
Multi Dimension Clusterd tables.
If one updates one of the columns chosen as a dimension, the only way
DB2 can deal with this to maintain clustering is to delete the row where
it lived in its block and insert the row with the new dimension in its
proper block.
Apart from this I'd totally agree with Rhino.

Rhino wrote:
"robert" <gn*****@rcn.com> wrote in message
news:da**************************@posting.google.c om...
been ruminating on the question (mostly in a 390/v7 context) of
whether, and if so when, a row update becomes an insert/delete.

i assume that there is a threshold on the number of columns of
the table, or perhaps bytes, being updated where the engine just
decides, screw it, i'll just make a new one.

surfed this group and google, but couldn't find anything.

the context: we have some java folk who like to parametize/
generalize/exersize into what they call Data Access Objects, and
end up looping through a database result set based on column
metadata (thus not having to write any table specific code),
resetting all columns. makes for generatable code, but i for one
don't like it.

seems to be the worst possible performance scenario??

I'm a Java developer but I've never used Data Access Objects so I may not be
qualified to comment on this question.

However, I would be quite astonished if "the engine" _EVER_ "just decides,
screw it, I'll just make a new one". (I assume that when you say "the
engine" you mean the DB2 code itself, as opposed to some third party add-on
to DB2.)

Frankly, I've never heard so much as a whisper of a hint of a rumour of a
suggestion that DB2 could transform an SQL Update statement to an Insert
and/or a Delete and I've been working with DB2 in one capacity or another
for 20 years.

As far as I know, an Update is always an Update, a Delete is always a
Delete, and an Insert is always an Insert and none of these can change from
one to the other.

Of course, I *could* be wrong....

Having said that, an *application* which uses DB2 should be able to turn an
update statement into a delete/insert. For instance, if a user submitted a
query like this through an interface that I wrote:
update Employee
set salary = salary * 1.1
where empno = '000010'

I could imagine converting that to:
1) a delete that removed the current row for employee 000010
2) an insert to create a new row for employee 000010 but with a 10% raise in
salary.

Of course, the code to do this would also need a select to determine the
current values of all of the other columns in the original row so that they
could be copied to the new row during the insert.

However, there could easily be important side-issues with respect to related
data. For instance, if the Employee table in the example had dependent
tables, such as Employee_Health_Claims, doing the delete in the Employee
table could cause all rows of Employee_Health_Claims that relate to that
Employee to be deleted if a DELETE CASCADE rule was in effect. (And rows in
tables dependent on Employee_Health_Claims might also be deleted if the
DELETE CASCADE rule was in effect on this foreign keys.)

By the same token, the delete in the Employee table would fail if there was
a DELETE RESTRICT rule between Employee and Employee_Health_Claims. You
would have to consider Referential Integrity issues very carefully if you
chose to convert an Update into a Delete/Insert combination.

After all, you wouldn't want an update in one table to cause all sorts of
data to be deleted just because you thought you might get a slight advantage
by turning one Update into a Delete followed by an Insert.

Since I'm not sure if I really understood the intent of your question, I
don't know if this answers it. If not, perhaps you can clarify what you are
after. Then I - or others on this newsgroup - could try again.

Rhino


--
Pierre Saint-Jacques - Reply to: sesconsjunk at attglobaljunk dot com
Reconstruct address: Remove the two junk and replace at and dot by
their symbols.
IBM DB2 Cerified Solutions Expert - Administration
SES Consultants Inc.
Nov 12 '05 #3

P: n/a
I'd beg to differ just a little bit here.
IN DB2 UDB for LUW:
Multi Dimension Clusterd tables.
If one updates one of the columns chosen as a dimension, the only way
DB2 can deal with this to maintain clustering is to delete the row where
it lived in its block and insert the row with the new dimension in its
proper block.
Apart from this I'd totally agree with Rhino.

Rhino wrote:
"robert" <gn*****@rcn.com> wrote in message
news:da**************************@posting.google.c om...
been ruminating on the question (mostly in a 390/v7 context) of
whether, and if so when, a row update becomes an insert/delete.

i assume that there is a threshold on the number of columns of
the table, or perhaps bytes, being updated where the engine just
decides, screw it, i'll just make a new one.

surfed this group and google, but couldn't find anything.

the context: we have some java folk who like to parametize/
generalize/exersize into what they call Data Access Objects, and
end up looping through a database result set based on column
metadata (thus not having to write any table specific code),
resetting all columns. makes for generatable code, but i for one
don't like it.

seems to be the worst possible performance scenario??

I'm a Java developer but I've never used Data Access Objects so I may not be
qualified to comment on this question.

However, I would be quite astonished if "the engine" _EVER_ "just decides,
screw it, I'll just make a new one". (I assume that when you say "the
engine" you mean the DB2 code itself, as opposed to some third party add-on
to DB2.)

Frankly, I've never heard so much as a whisper of a hint of a rumour of a
suggestion that DB2 could transform an SQL Update statement to an Insert
and/or a Delete and I've been working with DB2 in one capacity or another
for 20 years.

As far as I know, an Update is always an Update, a Delete is always a
Delete, and an Insert is always an Insert and none of these can change from
one to the other.

Of course, I *could* be wrong....

Having said that, an *application* which uses DB2 should be able to turn an
update statement into a delete/insert. For instance, if a user submitted a
query like this through an interface that I wrote:
update Employee
set salary = salary * 1.1
where empno = '000010'

I could imagine converting that to:
1) a delete that removed the current row for employee 000010
2) an insert to create a new row for employee 000010 but with a 10% raise in
salary.

Of course, the code to do this would also need a select to determine the
current values of all of the other columns in the original row so that they
could be copied to the new row during the insert.

However, there could easily be important side-issues with respect to related
data. For instance, if the Employee table in the example had dependent
tables, such as Employee_Health_Claims, doing the delete in the Employee
table could cause all rows of Employee_Health_Claims that relate to that
Employee to be deleted if a DELETE CASCADE rule was in effect. (And rows in
tables dependent on Employee_Health_Claims might also be deleted if the
DELETE CASCADE rule was in effect on this foreign keys.)

By the same token, the delete in the Employee table would fail if there was
a DELETE RESTRICT rule between Employee and Employee_Health_Claims. You
would have to consider Referential Integrity issues very carefully if you
chose to convert an Update into a Delete/Insert combination.

After all, you wouldn't want an update in one table to cause all sorts of
data to be deleted just because you thought you might get a slight advantage
by turning one Update into a Delete followed by an Insert.

Since I'm not sure if I really understood the intent of your question, I
don't know if this answers it. If not, perhaps you can clarify what you are
after. Then I - or others on this newsgroup - could try again.

Rhino


--
Pierre Saint-Jacques - Reply to: sesconsjunk at attglobaljunk dot com
Reconstruct address: Remove the two junk and replace at and dot by
their symbols.
IBM DB2 Cerified Solutions Expert - Administration
SES Consultants Inc.
Nov 12 '05 #4

P: n/a
"Rhino" <rh****@NOSPAM.sympatico.ca> wrote in message news:<Yc********************@news20.bellglobal.com >...
"robert" <gn*****@rcn.com> wrote in message
news:da**************************@posting.google.c om...
been ruminating on the question (mostly in a 390/v7 context) of
whether, and if so when, a row update becomes an insert/delete.

i assume that there is a threshold on the number of columns of
the table, or perhaps bytes, being updated where the engine just
decides, screw it, i'll just make a new one.

surfed this group and google, but couldn't find anything.

the context: we have some java folk who like to parametize/
generalize/exersize into what they call Data Access Objects, and
end up looping through a database result set based on column
metadata (thus not having to write any table specific code),
resetting all columns. makes for generatable code, but i for one
don't like it.

seems to be the worst possible performance scenario??
I'm a Java developer but I've never used Data Access Objects so I may not be
qualified to comment on this question.

However, I would be quite astonished if "the engine" _EVER_ "just decides,
screw it, I'll just make a new one". (I assume that when you say "the
engine" you mean the DB2 code itself, as opposed to some third party add-on
to DB2.)


i have this irrepressible lower brain stem memory that some databases
(not for certain db2, hence the question), do just that.

Frankly, I've never heard so much as a whisper of a hint of a rumour of a
suggestion that DB2 could transform an SQL Update statement to an Insert
and/or a Delete and I've been working with DB2 in one capacity or another
for 20 years.

As far as I know, an Update is always an Update, a Delete is always a
Delete, and an Insert is always an Insert and none of these can change from
one to the other.

Of course, I *could* be wrong....

Having said that, an *application* which uses DB2 should be able to turn an
update statement into a delete/insert. For instance, if a user submitted a
query like this through an interface that I wrote:
update Employee
set salary = salary * 1.1
where empno = '000010'

I could imagine converting that to:
1) a delete that removed the current row for employee 000010
2) an insert to create a new row for employee 000010 but with a 10% raise in
salary.

Of course, the code to do this would also need a select to determine the
current values of all of the other columns in the original row so that they
could be copied to the new row during the insert.
thus handing over the responsibility for data concurrency to the application.
just the sort of thing that irritates my piles. see following.
and preceding.

However, there could easily be important side-issues with respect to related
data. For instance, if the Employee table in the example had dependent
tables, such as Employee_Health_Claims, doing the delete in the Employee
table could cause all rows of Employee_Health_Claims that relate to that
Employee to be deleted if a DELETE CASCADE rule was in effect. (And rows in
tables dependent on Employee_Health_Claims might also be deleted if the
DELETE CASCADE rule was in effect on this foreign keys.)

By the same token, the delete in the Employee table would fail if there was
a DELETE RESTRICT rule between Employee and Employee_Health_Claims. You
would have to consider Referential Integrity issues very carefully if you
chose to convert an Update into a Delete/Insert combination.

After all, you wouldn't want an update in one table to cause all sorts of
data to be deleted just because you thought you might get a slight advantage
by turning one Update into a Delete followed by an Insert.

Since I'm not sure if I really understood the intent of your question, I
don't know if this answers it. If not, perhaps you can clarify what you are
after. Then I - or others on this newsgroup - could try again.
two, related concerns (sorry if my OP was obtuse):

- updating every column of each updated row has *got* to be too expensive
for words; far more (if it's ever been quantified) than the 1 or 2 or 3
columns actually changed. are there published stats on the performance
impact?? that is: at what point, either number/type of columns, or
average byte count, etc. is the penalty so large that whatever (coder)
time saved in development by relying on a code generation tool is
overwhelmed by the run-time penalty of updating all columns?? OR, is
DB2 smart enough to see that the incoming column data matches in
table data, and says, "screw it. it ain't different. i ain't
touching it"???? in this scenario, using code generating tools is
not a bad thing, beyond the fact that folks soon forget what their
data looks like.

- if DB2 sees that the row is being nuked, does it escalate (as it does do
with locks) to insert/delete (or vice versa, of course). and, another
if, so is this more or less expensive than doing the in-place insert?
an optimizer might consider "all aspects", and thus, basically, make
a mistake from a performance point of view??

clearer? somewhat existential and theoretical. antidote for RNC
blathering.

Rhino

Nov 12 '05 #5

P: n/a

"robert" <gn*****@rcn.com> wrote in message
news:da**************************@posting.google.c om...
"Rhino" <rh****@NOSPAM.sympatico.ca> wrote in message news:<Yc********************@news20.bellglobal.com >...
"robert" <gn*****@rcn.com> wrote in message
news:da**************************@posting.google.c om...
been ruminating on the question (mostly in a 390/v7 context) of
whether, and if so when, a row update becomes an insert/delete.

i assume that there is a threshold on the number of columns of
the table, or perhaps bytes, being updated where the engine just
decides, screw it, i'll just make a new one.

surfed this group and google, but couldn't find anything.

the context: we have some java folk who like to parametize/
generalize/exersize into what they call Data Access Objects, and
end up looping through a database result set based on column
metadata (thus not having to write any table specific code),
resetting all columns. makes for generatable code, but i for one
don't like it.

seems to be the worst possible performance scenario??


I'm a Java developer but I've never used Data Access Objects so I may not be qualified to comment on this question.

However, I would be quite astonished if "the engine" _EVER_ "just decides, screw it, I'll just make a new one". (I assume that when you say "the
engine" you mean the DB2 code itself, as opposed to some third party add-on to DB2.)


i have this irrepressible lower brain stem memory that some databases
(not for certain db2, hence the question), do just that.

That's quite possible but I don't know the other databases well enough to
say yes or no with any certainty.

Frankly, I've never heard so much as a whisper of a hint of a rumour of a suggestion that DB2 could transform an SQL Update statement to an Insert
and/or a Delete and I've been working with DB2 in one capacity or another for 20 years.

As far as I know, an Update is always an Update, a Delete is always a
Delete, and an Insert is always an Insert and none of these can change from one to the other.

Of course, I *could* be wrong....

Having said that, an *application* which uses DB2 should be able to turn an update statement into a delete/insert. For instance, if a user submitted a query like this through an interface that I wrote:
update Employee
set salary = salary * 1.1
where empno = '000010'

I could imagine converting that to:
1) a delete that removed the current row for employee 000010
2) an insert to create a new row for employee 000010 but with a 10% raise in salary.

Of course, the code to do this would also need a select to determine the
current values of all of the other columns in the original row so that they could be copied to the new row during the insert.


thus handing over the responsibility for data concurrency to the

application. just the sort of thing that irritates my piles. see following.
and preceding.

However, there could easily be important side-issues with respect to related data. For instance, if the Employee table in the example had dependent
tables, such as Employee_Health_Claims, doing the delete in the Employee
table could cause all rows of Employee_Health_Claims that relate to that
Employee to be deleted if a DELETE CASCADE rule was in effect. (And rows in tables dependent on Employee_Health_Claims might also be deleted if the
DELETE CASCADE rule was in effect on this foreign keys.)

By the same token, the delete in the Employee table would fail if there was a DELETE RESTRICT rule between Employee and Employee_Health_Claims. You
would have to consider Referential Integrity issues very carefully if you chose to convert an Update into a Delete/Insert combination.

After all, you wouldn't want an update in one table to cause all sorts of data to be deleted just because you thought you might get a slight advantage by turning one Update into a Delete followed by an Insert.

Since I'm not sure if I really understood the intent of your question, I
don't know if this answers it. If not, perhaps you can clarify what you are after. Then I - or others on this newsgroup - could try again.
two, related concerns (sorry if my OP was obtuse):

- updating every column of each updated row has *got* to be too expensive
for words; far more (if it's ever been quantified) than the 1 or 2 or 3
columns actually changed. are there published stats on the performance
impact?? that is: at what point, either number/type of columns, or
average byte count, etc. is the penalty so large that whatever (coder)
time saved in development by relying on a code generation tool is
overwhelmed by the run-time penalty of updating all columns?? OR, is
DB2 smart enough to see that the incoming column data matches in
table data, and says, "screw it. it ain't different. i ain't
touching it"???? in this scenario, using code generating tools is
not a bad thing, beyond the fact that folks soon forget what their
data looks like.

I don't know precisely what happens in DB2 with respect to updates; after
all, IBM doesn't publish the source code so I wouldn't know.

However, I have always understood that DB2 stores data as rows, that rows
are stored in pages, and DB2 works with pages of data in its bufferpools. In
other words, DB2 isn't doing separate I/Os to get each value on a row.
Furthermore, I've always believed that DB2 only updates the columns that are
in the SET clause of the Update statement and doesn't attempt to rewrite
columns that aren't changed. Again, that is just my *belief*; I can't say
that with certainty without looking at the source code. If anyone who is
absolutely certain can confirm or deny that belief, I'd appreciate it.

So I think the actual behaviour of an application depends on the Update
statement that it generates. If an application - or application generator -
puts every column of the table in the SET clause of its Update statements,
even if the column value isn't being changed, I'd expect that to be slower.
But that would be the fault of the application or generator, not DB2.
- if DB2 sees that the row is being nuked, does it escalate (as it does do
with locks) to insert/delete (or vice versa, of course). and, another
if, so is this more or less expensive than doing the in-place insert?
an optimizer might consider "all aspects", and thus, basically, make
a mistake from a performance point of view??

DB2's Lock Manager can certainly escalate locks and does that when that is
required. However, you should understand that the Lock Manager works at the
row (or page, or table, or tablespace, or database level), not at the level
of individual fields. I'm not aware of any circumstances where it can lock
less than a full row. Lock escalation is always about locking more rows (or
pages), never about locking more fields on one row.

Again, I don't think it is possible for DB2 to convert an Update to a
Delete/Insert, except in that one special case that Pierre noted.

As always, I assume that others on this newsgroup will correct me if I've
inadvertently said anything wrong.

Rhino
Nov 12 '05 #6

P: n/a
Ian
Pierre Saint-Jacques wrote:
I'd beg to differ just a little bit here.
IN DB2 UDB for LUW:
Multi Dimension Clusterd tables.
If one updates one of the columns chosen as a dimension, the only way
DB2 can deal with this to maintain clustering is to delete the row where
it lived in its block and insert the row with the new dimension in its
proper block.


The same applies for updating the partitioning key for a table in
a partitioned database -- this may result in a delete/insert if the
row would need to be migrated to a different database partition.

-----= Posted via Newsfeeds.Com, Uncensored Usenet News =-----
http://www.newsfeeds.com - The #1 Newsgroup Service in the World!
-----== Over 100,000 Newsgroups - 19 Different Servers! =-----
Nov 12 '05 #7

P: n/a
Things may have changed but I've always understood DB2's update to deal
with the undo/redo info required and only that for an update.
I used to know(?), things may have changed, that DB2 would pick up the
first column of a row to be changed and all columns from there to the
last column mentioned in the set. Not to deal with the whole row.

As Rhino mentions, in DB2 UDB for LUW, for updates, tables get locked
and rows may get locked. If rows do get locked, locklist and maxlocks
(cfg parms) will govern whether or not there is escalation. Escalation
is always to a strict table lock.
HTH, Pierre.

Rhino wrote:
"robert" <gn*****@rcn.com> wrote in message
news:da**************************@posting.google.c om...
"Rhino" <rh****@NOSPAM.sympatico.ca> wrote in message


news:<Yc********************@news20.bellglobal.com >...
"robert" <gn*****@rcn.com> wrote in message
news:da**************************@posting.googl e.com...

been ruminating on the question (mostly in a 390/v7 context) of
whether, and if so when, a row update becomes an insert/delete.

i assume that there is a threshold on the number of columns of
the table, or perhaps bytes, being updated where the engine just
decides, screw it, i'll just make a new one.

surfed this group and google, but couldn't find anything.

the context: we have some java folk who like to parametize/
generalize/exersize into what they call Data Access Objects, and
end up looping through a database result set based on column
metadata (thus not having to write any table specific code),
resetting all columns. makes for generatable code, but i for one
don't like it.

seems to be the worst possible performance scenario??

I'm a Java developer but I've never used Data Access Objects so I may
not be
qualified to comment on this question.

However, I would be quite astonished if "the engine" _EVER_ "just
decides,
screw it, I'll just make a new one". (I assume that when you say "the
engine" you mean the DB2 code itself, as opposed to some third party
add-on
to DB2.)


i have this irrepressible lower brain stem memory that some databases
(not for certain db2, hence the question), do just that.


That's quite possible but I don't know the other databases well enough to
say yes or no with any certainty.
Frankly, I've never heard so much as a whisper of a hint of a rumour of
a
suggestion that DB2 could transform an SQL Update statement to an Insert
and/or a Delete and I've been working with DB2 in one capacity or
another
for 20 years.

As far as I know, an Update is always an Update, a Delete is always a
Delete, and an Insert is always an Insert and none of these can change
from
one to the other.

Of course, I *could* be wrong....

Having said that, an *application* which uses DB2 should be able to turn
an
update statement into a delete/insert. For instance, if a user submitted
a
query like this through an interface that I wrote:
update Employee
set salary = salary * 1.1
where empno = '000010'

I could imagine converting that to:
1) a delete that removed the current row for employee 000010
2) an insert to create a new row for employee 000010 but with a 10%
raise in
salary.

Of course, the code to do this would also need a select to determine the
current values of all of the other columns in the original row so that
they
could be copied to the new row during the insert.


thus handing over the responsibility for data concurrency to the


application.
just the sort of thing that irritates my piles. see following.
and preceding.

However, there could easily be important side-issues with respect to
related
data. For instance, if the Employee table in the example had dependent
tables, such as Employee_Health_Claims, doing the delete in the Employee
table could cause all rows of Employee_Health_Claims that relate to that
Employee to be deleted if a DELETE CASCADE rule was in effect. (And rows
in
tables dependent on Employee_Health_Claims might also be deleted if the
DELETE CASCADE rule was in effect on this foreign keys.)

By the same token, the delete in the Employee table would fail if there
was
a DELETE RESTRICT rule between Employee and Employee_Health_Claims. You
would have to consider Referential Integrity issues very carefully if
you
chose to convert an Update into a Delete/Insert combination.

After all, you wouldn't want an update in one table to cause all sorts
of
data to be deleted just because you thought you might get a slight
advantage
by turning one Update into a Delete followed by an Insert.

Since I'm not sure if I really understood the intent of your question, I
don't know if this answers it. If not, perhaps you can clarify what you
are
after. Then I - or others on this newsgroup - could try again.


two, related concerns (sorry if my OP was obtuse):

- updating every column of each updated row has *got* to be too expensive
for words; far more (if it's ever been quantified) than the 1 or 2 or 3
columns actually changed. are there published stats on the performance
impact?? that is: at what point, either number/type of columns, or
average byte count, etc. is the penalty so large that whatever (coder)
time saved in development by relying on a code generation tool is
overwhelmed by the run-time penalty of updating all columns?? OR, is
DB2 smart enough to see that the incoming column data matches in
table data, and says, "screw it. it ain't different. i ain't
touching it"???? in this scenario, using code generating tools is
not a bad thing, beyond the fact that folks soon forget what their
data looks like.


I don't know precisely what happens in DB2 with respect to updates; after
all, IBM doesn't publish the source code so I wouldn't know.

However, I have always understood that DB2 stores data as rows, that rows
are stored in pages, and DB2 works with pages of data in its bufferpools. In
other words, DB2 isn't doing separate I/Os to get each value on a row.
Furthermore, I've always believed that DB2 only updates the columns that are
in the SET clause of the Update statement and doesn't attempt to rewrite
columns that aren't changed. Again, that is just my *belief*; I can't say
that with certainty without looking at the source code. If anyone who is
absolutely certain can confirm or deny that belief, I'd appreciate it.

So I think the actual behaviour of an application depends on the Update
statement that it generates. If an application - or application generator -
puts every column of the table in the SET clause of its Update statements,
even if the column value isn't being changed, I'd expect that to be slower.
But that would be the fault of the application or generator, not DB2.

- if DB2 sees that the row is being nuked, does it escalate (as it does do
with locks) to insert/delete (or vice versa, of course). and, another
if, so is this more or less expensive than doing the in-place insert?
an optimizer might consider "all aspects", and thus, basically, make
a mistake from a performance point of view??


DB2's Lock Manager can certainly escalate locks and does that when that is
required. However, you should understand that the Lock Manager works at the
row (or page, or table, or tablespace, or database level), not at the level
of individual fields. I'm not aware of any circumstances where it can lock
less than a full row. Lock escalation is always about locking more rows (or
pages), never about locking more fields on one row.

Again, I don't think it is possible for DB2 to convert an Update to a
Delete/Insert, except in that one special case that Pierre noted.

As always, I assume that others on this newsgroup will correct me if I've
inadvertently said anything wrong.

Rhino


--
Pierre Saint-Jacques - Reply to: sesconsjunk at attglobaljunk dot com
Reconstruct address: Remove the two junk and replace at and dot by
their symbols.
IBM DB2 Cerified Solutions Expert - Administration
SES Consultants Inc.
Nov 12 '05 #8

P: n/a
I think an update on a Union ALL view WITH ROW MOVEMENT can also do that.

PM
Nov 12 '05 #9

P: n/a
Correct and also update to a range-clustered table.
When range partitioning become availbale, that too will have the same
behaviour.

To comment on the question what DB2 really updates in a "real" update.
DB2 actually ahndles teh fact that more elements are mentioned in the
SET clause (or before trigger) than ar eactually changed (SET c1 = c1).
By default these smarts are ON. There is a Db2 registry variable called
ASSUMEUPDATED (or something like that) which can be set to disable the
smarts (to shave some codepath in well behaved high performance
environments).
The requirement to be that smart indeed coems from teh fact that many
Apps don't bother to find out what was updated. They simply update all
the columns.
The savings, btw is not in the writing of the page. It's in the logging.
And DB2 indeed logs the stripe from the first changed column to the last
changed column.

Cheers
Serge
Nov 12 '05 #10

P: n/a
Serge Rielau <sr*****@ca.eye-bee-em.com> wrote in message news:<fB********************@twister01.bloor.is.ne t.cable.rogers.com>...
Correct and also update to a range-clustered table.
When range partitioning become availbale, that too will have the same
behaviour.

To comment on the question what DB2 really updates in a "real" update.
DB2 actually ahndles teh fact that more elements are mentioned in the
SET clause (or before trigger) than ar eactually changed (SET c1 = c1).
By default these smarts are ON. There is a Db2 registry variable called
ASSUMEUPDATED (or something like that) which can be set to disable the
smarts (to shave some codepath in well behaved high performance
environments).
The requirement to be that smart indeed coems from teh fact that many
Apps don't bother to find out what was updated. They simply update all
the columns. The savings, btw is not in the writing of the page. It's in the logging.
And DB2 indeed logs the stripe from the first changed column to the last
changed column.
kind of figured that part <G>

this is an LUW facility? or DB2 wide? (my case study is NT, so it
doesn't, for the moment, affect 390).

robert

Cheers
Serge

Nov 12 '05 #11

P: n/a
I have no clue whether DB2 for z/OS has a similar implementation.

Cheers
Serge
Nov 12 '05 #12

P: n/a
AK
> many
Apps don't bother to find out what was updated. They simply update all
the columns.


Just wanted to add that there may be a strong reason not to bother.
Let's assume I'm performing an array update, and I've bound 40
parameters. Should I be figuring out what's actually changed and
what's not, and issuing individual dynamic updates for each row, that
would be much slower. Keeping 2^40 prepared updates is also out of
question, is it not
Nov 12 '05 #13

P: n/a
ak************@yahoo.com (AK) wrote in message news:<46**************************@posting.google. com>...
many
Apps don't bother to find out what was updated. They simply update all
the columns.
Just wanted to add that there may be a strong reason not to bother.
Let's assume I'm performing

an array update
real relational databases (even just 1st normal form ones) don't
have arrays. don't you read date, or even celko? <G>

, and I've bound 40 parameters. Should I be figuring out what's actually changed and
what's not, and issuing individual dynamic updates for each row, that
would be much slower. Keeping 2^40 prepared updates is also out of
question, is it not

Nov 12 '05 #14

P: n/a
Real relational systems don't have cleint side logic ;-)
I think SQL is SQL and procedural is procedural.
But those two conecpts must talk with each other.
Wherher the academics like it or not.
And neither Java nor .Net are SQL friendly.

Cheers
Serge
Nov 12 '05 #15

P: n/a
AK
gn*****@rcn.com (robert) wrote in message news:<da*************************@posting.google.c om>...
ak************@yahoo.com (AK) wrote in message news:<46**************************@posting.google. com>...
many
Apps don't bother to find out what was updated. They simply update all
the columns.


Just wanted to add that there may be a strong reason not to bother.
Let's assume I'm performing

an array update


real relational databases (even just 1st normal form ones) don't
have arrays. don't you read date, or even celko? <G>


you probably don't know yet about binding arrays to parameters.
if you wish to learn a little bit, start here:

http://www-106.ibm.com/developerwork...04pooloth.html
Nov 12 '05 #16

P: n/a
ak************@yahoo.com (AK) wrote in message news:<46**************************@posting.google. com>...
gn*****@rcn.com (robert) wrote in message news:<da*************************@posting.google.c om>...
ak************@yahoo.com (AK) wrote in message news:<46**************************@posting.google. com>...
> many
> Apps don't bother to find out what was updated. They simply update all
> the columns.

Just wanted to add that there may be a strong reason not to bother.
Let's assume I'm performing an array update


real relational databases (even just 1st normal form ones) don't
have arrays. don't you read date, or even celko? <G>


you probably don't know yet about binding arrays to parameters.
if you wish to learn a little bit, start here:

http://www-106.ibm.com/developerwork...04pooloth.html


it was a pun on array (there was a <G>, after all). we use a framework,
pre-Struts but much like it, and jdbc, and indexed parameters to the
servlets. an interesting article, nonetheless.

<G><G>
bumps
Nov 12 '05 #17

This discussion thread is closed

Replies have been disabled for this discussion.