Re: SELECT * FROM LIMIT 1; is really slow - Mailing list pgsql-hackers
From Alvaro Herrera
Subject Re: SELECT * FROM LIMIT 1; is really slow
Date
Msg-id 20040528200319.GA3111@dcc.uchile.cl
Whole thread Raw
In response to Re: SELECT * FROM LIMIT 1; is really slow  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On Fri, May 28, 2004 at 03:48:11PM -0400, Tom Lane wrote:
> Alvaro Herrera <alvherre@dcc.uchile.cl> writes:
> > 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.  We only need to store the "borders" though.  Not even that: only
> > the start, because the end is what is current at AbortSubTransaction()
> > time.
> 
> Nope.  Think about sub-subtransactions.

They are all aborted if the parent is, so

BEGIN;BEGIN;                -- cid = 1    BEGIN;            -- cid = 2        INSERT INTO foo VALUES (1)    -- cid=3
COMMIT;ROLLBACK;       -- aborts from Cid 1 to Cid 3-- here we can't see the tuple because Xmin == my-xid-- and Cmin=1
isaborted
 
COMMIT;

I assume this is how you think it works, isn't it?  Because if not I am
in serious trouble.  But if it is, then CommandIds from 1 ("start Cid")
and 3 ("current Cid") are aborted.  And this can be kept in the master
bitmap --- in fact, I didn't think about another one.

-- 
Alvaro Herrera (<alvherre[a]dcc.uchile.cl>)
"Un poeta es un mundo encerrado en un hombre" (Victor Hugo)



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: On query rewrite
Next
From: Tom Lane
Date:
Subject: Re: SELECT * FROM LIMIT 1; is really slow