Skip site navigation (1) Skip section navigation (2)

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
Message-ID: 20040529015953.GA10492@dcc.uchile.cl (view raw or flat)
Thread:
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]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)


In response to

Responses

pgsql-hackers by date

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

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group