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

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-29 01:59:53
Views: Raw Message | Whole Thread | Download mbox
Lists: 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]>)
"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)

In response to


Browse pgsql-hackers by date

  From Date Subject
Next Message Bruce Momjian 2004-05-29 03:11:27 Re: Nested xacts: looking for testers and review
Previous Message Sean Chittenden 2004-05-29 01:20:10 Re: temp tables broken in CVS HEAD?