Re: SELECT * FROM LIMIT 1; is really slow Поиск
Список
Период
Сортировка
От Manfred Koizar
Тема Re: SELECT * FROM LIMIT 1; is really slow
Дата
Msg-id rkfcb05l29kfpmcle0di3dtaifindmv0da@email.aon.at
обсуждение исходный текст
Ответ на Re: SELECT * FROM LIMIT 1; is really slow  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: SELECT * FROM LIMIT 1; is really slow
Список 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 по дате отправления:

Предыдущее
От: Neil Conway
Дата:
Сообщение: Re: list rewrite committed
Следующее
От: "Ramanujam H S Iyengar"
Дата:
Сообщение: How to get the Oid of the Primary key relation ??