Re: [HACKERS] SELECT * FROM LIMIT 1; is really slow

Fri, 28 May 2004 14:07:59 -0700

On Fri, May 28, 2004 at 03:48:11PM -0400, Tom Lane wrote:
> Alvaro Herrera <[EMAIL PROTECTED]> 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 is aborted
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)


---------------------------(end of broadcast)---------------------------
TIP 9: the planner will ignore your desire to choose an index scan if your
      joining column's datatypes do not match

Reply via email to