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 20040529015953.GA10492@dcc.uchile.cl
Whole thread Raw
In response to Re: SELECT * FROM LIMIT 1; is really slow  (Alvaro Herrera <alvherre@dcc.uchile.cl>)
Responses Re: SELECT * FROM LIMIT 1; is really slow  (Manfred Koizar <mkoi-pg@aon.at>)
List pgsql-hackers
I wrote a while ago

> So pg_subtrans remains the same, and we assign a new Xid to each
> subtransaction.  Each tuple gets Xmin/Xmax according to the Xid of the
> current subtransaction.  Within the transaction tree we don't use the
> Xid to check for visibility, but Cmin/Cmax and the abort bitmap.

... and meanwhile I forgot why this subthread started: I haven't solved
the original problem, which is that I want to avoid enlarging the
HeapTupleHeader.  But currently there is need for storing both a Cmin
and a Xmax :-(

Manfred: the code you read adds a single bit to the infomask, which is
there basically to be able to say whether the Cmin has been overwritten
with a Xmax.  So the assumption was that when we see that this has
happenned, the Cmin is no longer important (== every future command can
already see the tuple), and we have to check the Xmax in pg_clog to see
if the deleting subtransaction has aborted (in which case the tuple is
visible to us).

This idea was a result of a couple of hour of chat with Bruce where I
explained that I didn't want to enlarge the HeapTupleHeader, and he came
up with the bit idea.

-- 
Alvaro Herrera (<alvherre[a]dcc.uchile.cl>)
"En las profundidades de nuestro inconsciente hay una obsesiva necesidad
de un universo lógico y coherente. Pero el universo real se halla siempre
un paso más allá de la lógica" (Irulan)



pgsql-hackers by date:

Previous
From: Sean Chittenden
Date:
Subject: Re: temp tables broken in CVS HEAD?
Next
From: Bruce Momjian
Date:
Subject: Re: Nested xacts: looking for testers and review