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

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

From: Manfred Koizar <mkoi-pg(at)aon(dot)at>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: 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-27 19:52:30
Message-ID: rkfcb05l29kfpmcle0di3dtaifindmv0da@email.aon.at (view raw or flat)
Thread:
Lists: pgsql-hackers
On Thu, 27 May 2004 14:23:07 -0400, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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.

Servus
 Manfred

In response to

Responses

pgsql-hackers by date

Next:From: Ramanujam H S IyengarDate: 2004-05-27 20:07:19
Subject: How to get the Oid of the Primary key relation ??
Previous:From: Neil ConwayDate: 2004-05-27 19:36:53
Subject: Re: list rewrite committed

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