Skip site navigation (1) Skip section navigation (2)

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: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackerspgsql-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


pgsql-performance by date

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

pgsql-hackers by date

Next:From: mlwDate: 2003-02-01 04:44:10
Subject: Re: [mail] Re: Windows Build System
Previous:From: Dann CorbitDate: 2003-02-01 04:26:47
Subject: Re: [mail] Re: Windows Build System

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group