Re: Accelerating aggregates

From: Steve Atkins <steve(at)blighty(dot)com>
To: pgsql-hackers(at)postgresql(dot)org
Subject: Re: Accelerating aggregates
Date: 2004-06-11 17:00:26
Message-ID: 20040611170026.GA16481@gp.word-to-the-wise.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Fri, Jun 11, 2004 at 12:17:57PM -0400, Greg Stark wrote:
> Steve Atkins <steve(at)blighty(dot)com> writes:
>
> > So, if you take a local snapshot of the global at the beginning of
> > your transaction then the visible changes at any point are those from
> > transactions that commited before your transaction started. That's
> > well-defined, at least, and appears to be pretty much the same as the
> > standard read commited isolation level.
>
> no, read committed would see any other updates that have been committed since
> the start of your transaction.

Uhm... only updates within the current transaction. So if you merge the
global state and the local state that's exactly what you'll see.

> For some linear aggregates you could start with the initcond, apply all the
> local updates and whenever you have to read the actual value then use the
> global variable at that time. But not all aggregates can be handled that way.
> I think all the standard ones could be though, sum(), count(), stddev(), etc.

I think all the standard ones can (anything with an associative update
function, if I remember my math correctly). And my thought was not
that this would be a neato transparent optimization that the parser
would use directly in all cases, rather that it would be a hack
explicitly setup by the DBA for those specific cases where they need
it.

Cheers,
Steve

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Bruce Momjian 2004-06-11 17:02:52 Re: Improving postgresql.conf
Previous Message pgsql 2004-06-11 16:39:18 Re: [pgsql-hackers-win32] Tablespaces