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
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 |