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 20040527205024.GB3603@dcc.uchile.cl
Whole thread Raw
In response to Re: SELECT * FROM LIMIT 1; is really slow  (Manfred Koizar <mkoi-pg@aon.at>)
Responses Re: SELECT * FROM LIMIT 1; is really slow  (Manfred Koizar <mkoi-pg@aon.at>)
List pgsql-hackers
On Thu, May 27, 2004 at 09:52:30PM +0200, Manfred Koizar wrote:

> I have no clear explanation at the moment, just some fuzzy ideas that
> are beginning to crystallise.  I'm messing around with heap tuple
> headers again, and the Xvac field seems to get in the way, unless I can
> cut down the number of different scenarios where it is needed.

Now you are on the subject, can I ask you to take a peek at what I did
regarding tuple headers?

At first I thought I'd have to add back Xmax as a field on its own, but
later (in chat with Bruce) I arrived to the conclusion that it isn't
really necessary, and I only added a bit to the infomask to flag when
the Cmin is overridden with Xmax.

However I'm not convinced that this is enough --- is there a situation
on which we should need to peek at Cmin after setting Xmax for a
particusar tuple?

The problem was

BEGIN;insert into foo values (1)begin    delete from foorollback-- at this point the tuple shold be visible,-- but it
hasmy Xid as Xmin and Cmin was -- overriden with Xmax
 
commit

I'd appreciate your (Manfred's and Tom's) comments on the topic.

-- 
Alvaro Herrera (<alvherre[a]dcc.uchile.cl>)
"And as an added bonus, now my computer goes to the toilet for me, leaving me
free to spend time on more useful activities! yay slug codefests!" (C. Parker)



pgsql-hackers by date:

Previous
From: Bruce Momjian
Date:
Subject: Win32, PITR, nested transactions, tablespaces
Next
From: pgsql@mohawksoft.com
Date:
Subject: Re: tablespaces and DB administration