Re: [PERFORM] not using index for select min(...)

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Sean Chittenden <sean(at)chittenden(dot)org>
Cc: Josh Berkus <josh(at)agliodbs(dot)com>, Don Bowman <don(at)sandvine(dot)com>, "'pgsql-hackers(at)postgresql(dot)org'" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: [PERFORM] not using index for select min(...)
Date: 2003-02-01 04:35:32
Message-ID: 4278.1044074132@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers pgsql-performance

Sean Chittenden <sean(at)chittenden(dot)org> writes:
> Now, there are some obvious problems:

You missed the real reason why this will never happen: it completely
kills any prospect of concurrent updates. If transaction A has issued
an update on some row, and gone and modified the relevant aggregate
cache entries, what happens when transaction B wants to update another
row? It has to wait for A to commit or not, so it knows whether to
believe A's changes to the aggregate cache entries.

For some aggregates you could imagine an 'undo' operator to allow
A's updates to be retroactively removed even after B has applied its
changes. But that doesn't work very well in general. And in any case,
you'd have to provide serialization interlocks on physical access to
each of the aggregate cache entries. That bottleneck applied to every
update would be likely to negate any possible benefit from using the
cached values.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message mlw 2003-02-01 04:44:10 Re: [mail] Re: Windows Build System
Previous Message Dann Corbit 2003-02-01 04:26:47 Re: [mail] Re: Windows Build System

Browse pgsql-performance by date

  From Date Subject
Next Message Curt Sampson 2003-02-01 05:07:00 Re: One large v. many small
Previous Message Sean Chittenden 2003-02-01 04:09:54 Re: [PERFORM] not using index for select min(...)