| From: | "Jim C(dot) Nasby" <jnasby(at)pervasive(dot)com> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| 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-10 19:00:11 |
| Message-ID: | 20060510190011.GO99570@pervasive.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers pgsql-performance |
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?
Even if you rollback you should still be able to just update a row
counter because nothing else would be able to see what was rolled back.
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?
--
Jim C. Nasby, Sr. Engineering Consultant jnasby(at)pervasive(dot)com
Pervasive Software http://pervasive.com work: 512-231-6117
vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Jim C. Nasby | 2006-05-10 19:06:17 | Re: [HACKERS] Big IN() clauses etc : feature proposal |
| Previous Message | Zdenek Kotala | 2006-05-10 18:46:41 | [TODO] Allow commenting of variables ... |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Jim C. Nasby | 2006-05-10 19:06:17 | Re: [HACKERS] Big IN() clauses etc : feature proposal |
| Previous Message | Jim C. Nasby | 2006-05-10 18:40:35 | Re: [HACKERS] Big IN() clauses etc : feature proposal |