Re: Accelerating aggregates

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Steve Atkins <steve(at)blighty(dot)com>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: Accelerating aggregates
Date: 2004-06-11 17:49:18
Message-ID: 16614.1086976158@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Steve Atkins <steve(at)blighty(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Andreas Pflug 2004-06-11 17:51:41 Re: Compiling libpq with VisualC
Previous Message Dann Corbit 2004-06-11 17:29:02 Re: [pgsql-hackers-win32] Tablespaces