Skip site navigation (1) Skip section navigation (2)

Re: [HACKERS] Big IN() clauses etc : feature proposal

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: "Jim C(dot) Nasby" <jnasby(at)pervasive(dot)com>
Cc: PFC <lists(at)peufeu(dot)com>, Mitchell Skinner <mitch(at)arctur(dot)us>, pgsql-performance(at)postgresql(dot)org, pgsql-hackers(at)postgresql(dot)org
Subject: Re: [HACKERS] Big IN() clauses etc : feature proposal
Date: 2006-05-11 00:31:54
Message-ID: 22558.1147307514@sss.pgh.pa.us (view raw or flat)
Thread:
Lists: pgsql-hackerspgsql-performance
"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

Responses

pgsql-performance by date

Next:From: Tom LaneDate: 2006-05-11 01:20:05
Subject: Re: Same query - Slow in production
Previous:From: Brian WipfDate: 2006-05-10 23:56:18
Subject: Re: Same query - Slow in production

pgsql-hackers by date

Next:From: Tom LaneDate: 2006-05-11 01:24:11
Subject: Re: BEGIN inside transaction should be an error
Previous:From: Tom LaneDate: 2006-05-10 23:18:39
Subject: pgsql: Clean up code associated with updating pg_class statistics

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group