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

Manfred Koizar <mkoi-pg(at)aon(dot)at> writes:
> XXXXXXXX XXXXXXXX XXXXXXXX XXXXXX.. ..y.....

> 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.

> AFAICS this would make vacuum.c much simpler (no more chain moves).

How will it do that? I think you'd have to not move *any* updated
tuples to be sure you don't need the chain-move mechanism. Not moving
the outdated tuple isn't sufficient, you can't move the one it points at
either.

> Clearly this change alone doesn't have any merit. But would such a
> patch have any chance of being accepted, if it facilitates improvements
> in other areas?

I'm disinclined to mess with VACUUM FULL without a clearer explanation
of where you're headed. So far as I can see, you're simply going to
make VACUUM FULL less effective with no stated benefit.

(BTW, it now occurs to me that CLUSTER and ALTER TABLE in their present
forms may be broken, because they only copy rows that are valid
according to SnapshotNow; this means that rows that are still visible to
old transactions could be lost. The lack of any attempt to preserve
update chain relationships seems ungood as well, if we might have old
transactions come along and try to update the table later.)

regards, tom lane