| 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 |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers pgsql-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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2006-05-11 01:24:11 | Re: BEGIN inside transaction should be an error |
| Previous Message | Tom Lane | 2006-05-10 23:18:39 | pgsql: Clean up code associated with updating pg_class statistics |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2006-05-11 01:20:05 | Re: Same query - Slow in production |
| Previous Message | Brian Wipf | 2006-05-10 23:56:18 | Re: Same query - Slow in production |