"Jim C. Nasby" <jnasby(at)pervasive(dot)com> writes:
> On Tue, May 09, 2006 at 03:13:01PM -0400, Tom Lane wrote:
>> PFC <lists(at)peufeu(dot)com> writes:
>>> Fun thing is, the rowcount from a temp table (which is the problem here)
>>> should be available without ANALYZE ; as the temp table is not concurrent,
>>> it would be simple to inc/decrement a counter on INSERT/DELETE...
>> No, because MVCC rules still apply.
> But can anything ever see more than one version of what's in the table?
Yes, because there can be more than one active snapshot within a single
transaction (think about volatile functions in particular).
> Speaking of which, if a temp table is defined as ON COMMIT DROP or
> DELETE ROWS, there shouldn't be any need to store xmin/xmax, only
> cmin/cmax, correct?
No; you forgot about subtransactions.
regards, tom lane
In response to
pgsql-performance by date
|Next:||From: Tom Lane||Date: 2006-05-11 01:20:05|
|Subject: Re: Same query - Slow in production |
|Previous:||From: Brian Wipf||Date: 2006-05-10 23:56:18|
|Subject: Re: Same query - Slow in production|
pgsql-hackers by date
|Next:||From: Tom Lane||Date: 2006-05-11 01:24:11|
|Subject: Re: BEGIN inside transaction should be an error |
|Previous:||From: Tom Lane||Date: 2006-05-10 23:18:39|
|Subject: pgsql: Clean up code associated with updating pg_class statistics |