From: | Steve Atkins <steve(at)blighty(dot)com> |
---|---|
To: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Accelerating aggregates |
Date: | 2004-06-11 15:26:05 |
Message-ID: | 20040611152604.GA14405@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 09:27:07AM +0100, Richard Huxton wrote:
> >If the transaction is rolled back, the local state variable is
> >thrown away. If the transaction is commited and the local state
> >variable has been invalidated then the global state variable is
> >invalidated, otherwise the global state variable is updated using
> >a a state merge function, specific to the aggregate.
>
> Isn't this going to have visibility issues wrt other backends? How do I
> know what transactions have updated the global and what haven't and
> which I should currently be seeing?
The global is only updated at transaction commit.
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.
> I'm not sure that there is a solution simpler than the "insert +1/-1
> into summary table" that gets discussed.
That's fairly slow and painful.
Cheers,
Steve
From | Date | Subject | |
---|---|---|---|
Next Message | Greg Stark | 2004-06-11 15:33:19 | Re: Tablespaces |
Previous Message | pgsql | 2004-06-11 15:16:19 | Re: Accelerating aggregates |