At 10:47 AM 14-07-02 +0300, you wrote:

> > I don't want to waste a lot of time in conjecturing this, since it's not
> > something that would (should) be done to production data and wouldn't be a
> > requirement for any transaction-capable DBMS. Why is it an important test
> > for you?
>
>Because if it's slow in a situation like this one, I could expect to be slow
>for something that's a requiement for a DBMS.

Nonsense. It is slow when asked to update the same 30,000 rows twice in a
single transaction. Would you write an application like that? What would
its purpose be? A well-designed application would not attempt to update
deltas, either - not even on a searched update. The client app would not
post a delta until the user was ready to post it.

>And I know that' sometimes it happens to modifiy the same record twice in a
>single transaction. Think of an user editing a record, posting it, not
>ending the transaction, and changing it again.

Not in applications I write. But if you need to make this a possibility,
you would use some sort of client-side caching, not post multiple deltas
for the same original row.

>It does not need to locate each delta record, since it's changing data
>changed in current transaction, so it's changing only the current record.

Are you kidding? This was your SQL:

update "table_name" set "field_name"='666';

That's updating 30,000 rows, then going back and updating the same 30,000
rows again. The second time through it has to check each of the original
rows as well, to determine whether any other transactions have updates
pending on them...

heLen

All for Open and Open for All
Firebird Open SQL Database · http://firebirdsql.org ·
http://users.tpg.com.au/helebor/
_______________________________________________________