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