Steve Atkins <[EMAIL PROTECTED]> writes:
> On Fri, Jun 11, 2004 at 12:17:57PM -0400, Greg Stark wrote:
>
> > no, read committed would see any other updates that have been committed since
> > the start of your transaction.
>
> Uhm... only updates within the current transaction.
No, "read commit
On Fri, Jun 11, 2004 at 01:49:18PM -0400, Tom Lane wrote:
> Steve Atkins <[EMAIL PROTECTED]> 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 SetQ
Steve Atkins <[EMAIL PROTECTED]> 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
On Fri, Jun 11, 2004 at 12:17:57PM -0400, Greg Stark wrote:
> Steve Atkins <[EMAIL PROTECTED]> writes:
>
> > 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 trans
Steve Atkins <[EMAIL PROTECTED]> writes:
> 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 pr
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 glob
[snip]
I've been harping on this problem myself the last couple days.
A summary table with frequent vacuums is your best bet for the existing
versions of PostgreSQL. It is, IMHO, suboptimal, but a workable solution
depending on the expected database load.
Right now I am exploring the possibility
Steve Atkins wrote:
Stop me if you've heard this before.
I'm looking at fast calculation of aggregates (sum(), max(), count())
across large tables, or across fairly simply defined subsets of those
tables.
Lets say that, for a given aggregate function on a given table (with a
given where clause, per
Stop me if you've heard this before.
I'm looking at fast calculation of aggregates (sum(), max(), count())
across large tables, or across fairly simply defined subsets of those
tables.
Lets say that, for a given aggregate function on a given table (with a
given where clause, perhaps), each postg
