Re: SELECT * FROM LIMIT 1; is really slow - Mailing list pgsql-hackers
From Manfred Koizar
Subject Re: SELECT * FROM LIMIT 1; is really slow
Date
Msg-id rkfcb05l29kfpmcle0di3dtaifindmv0da@email.aon.at
Whole thread Raw
In response to Re: SELECT * FROM LIMIT 1; is really slow  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: SELECT * FROM LIMIT 1; is really slow  (Alvaro Herrera <alvherre@dcc.uchile.cl>)
List pgsql-hackers
On Thu, 27 May 2004 14:23:07 -0400, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> and when y is updated the new version will be stored in a lower block
>
>Oh?  What makes you think that?  I see no guarantee of it.

You're right, I see only a tendency, because the majority of free space
is before the last block (obviously).  But don't we try to store the new
version on the same block as the old version?  That'd weaken my argument
a bit.

>I think you'd have to not move *any* updated
>tuples to be sure you don't need the chain-move mechanism.

Yes, per definitionem (move only tuples that are visible to all).

>I'm disinclined to mess with VACUUM FULL without a clearer explanation
>of where you're headed.

Have no fear.  I won't change anything in the near term.  As you were
talking about the future of VACUUM FULL,  I thought this might be a good
opportunity to ask.  The fact that you didn't outright reject the idea
is good enough for now.

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.

ServusManfred


pgsql-hackers by date:

Previous
From: Neil Conway
Date:
Subject: Re: list rewrite committed
Next
From: "Ramanujam H S Iyengar"
Date:
Subject: How to get the Oid of the Primary key relation ??