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

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