| From: | Alvaro Herrera <alvherre(at)dcc(dot)uchile(dot)cl> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | Manfred Koizar <mkoi-pg(at)aon(dot)at>, David Blasby <dblasby(at)refractions(dot)net>, pgsql-hackers(at)postgresql(dot)org |
| Subject: | Re: SELECT * FROM <table> LIMIT 1; is really slow |
| Date: | 2004-05-28 19:36:15 |
| Message-ID: | 20040528193615.GE2343@dcc.uchile.cl |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Fri, May 28, 2004 at 03:19:29PM -0400, Tom Lane wrote:
> We'd still need a plain CommandCounterIncrement facility, which means
> that actually a subtransaction would have to be a group of CIDs not just
> one.
Right, this is why I suggested runlength (the group is contiguous).
> So there'd also need to be a data structure showing the CIDs
> associated with each open subtransaction --- this is what you'd
> consult to go and set the "aborted" bits if the subxact rolls back.
Right. We only need to store the "borders" though. Not even that: only
the start, because the end is what is current at AbortSubTransaction()
time.
I'll try this.
--
Alvaro Herrera (<alvherre[a]dcc.uchile.cl>)
"El miedo atento y previsor es la madre de la seguridad" (E. Burke)
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2004-05-28 19:48:11 | Re: SELECT * FROM <table> LIMIT 1; is really slow |
| Previous Message | Andrew Dunstan | 2004-05-28 19:31:14 | Re: patch for different join result order on regression test for |