Re: SELECT * FROM <table> LIMIT 1; is really slow

On Fri, May 28, 2004 at 03:48:11PM -0400, Tom Lane wrote:
> Alvaro Herrera <alvherre(at)dcc(dot)uchile(dot)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 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)