Re: Accelerating aggregates
От | Steve Atkins |
---|---|
Тема | Re: Accelerating aggregates |
Дата | |
Msg-id | 20040611180613.GB16876@gp.word-to-the-wise.com обсуждение исходный текст |
Ответ на | Re: Accelerating aggregates (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-hackers |
On Fri, Jun 11, 2004 at 01:49:18PM -0400, Tom Lane wrote: > 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. Yup, though that's going to be acquire lock, memcpy, release lock and there's unlikely to be more than a few hundred bytes of state. > 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. Yeah, that's the implementation detail that's going to really kill the idea in most cases. > 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. I think you're right, but it was interesting to consider briefly. Cheers, Steve
В списке pgsql-hackers по дате отправления: