Re: Accelerating aggregates - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Accelerating aggregates
Date
Msg-id 16614.1086976158@sss.pgh.pa.us
Whole thread Raw
In response to Re: Accelerating aggregates  (Steve Atkins <steve@blighty.com>)
Responses Re: Accelerating aggregates  (Steve Atkins <steve@blighty.com>)
List pgsql-hackers
Steve Atkins <steve@blighty.com> writes:
> 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.

The only way this would work is if at every SetQuerySnapshot() you copy
*all* of the global variables as part of the snapshot.  You'd have to
copy them all since you don't know which ones you'll need for the next
query.  To avoid race conditions, you'd need to lock out transaction
commits while you are doing this copying.

I think there are also race conditions involved in transaction commit,
since there's no way to make the update of the global state be atomic
with the actual transaction commit ... unless perhaps you want to hold
a lock on the global state area while committing.

All in all, I think the overhead of this scheme would be enormous.  It
implies significant costs during every transaction start and commit,
whether or not that transaction is getting any benefit.
        regards, tom lane


pgsql-hackers by date:

Previous
From: "Dann Corbit"
Date:
Subject: Re: [pgsql-hackers-win32] Tablespaces
Next
From: Alvaro Herrera
Date:
Subject: Re: msession for PostgreSQL?