Re: Recalculating OldestXmin in a long-running vacuum

Поиск
Список
Период
Сортировка
От Heikki Linnakangas
Тема Re: Recalculating OldestXmin in a long-running vacuum
Дата
Msg-id 45AD17AE.5050603@enterprisedb.com
обсуждение исходный текст
Ответ на Re: Recalculating OldestXmin in a long-running vacuum  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: Recalculating OldestXmin in a long-running vacuum  (Gregory Stark <gsstark@mit.edu>)
Список pgsql-patches
Tom Lane wrote:
> Heikki Linnakangas <heikki@enterprisedb.com> writes:
>> It seems to me that we could easily reclaim a bit more dead tuples in a
>> vacuum by recalculating the OldestXmin every now and then.
>
> Doesn't this break relfrozenxid maintenance?

Not AFAICS. relfrozenxid is nowadays updated with FreezeLimit.

> In any case I'd like to
> see some evidence of significant real-world benefit before adding such
> a conceptual wart ...

I've asked our testers to do a TPC-C run with and without the
patch. I'm not expecting it to make a huge difference there, but if
you're using a big cost delay, it could make quite a difference for such
a simple thing.

> The procarray.c change scares me as well; I'm pretty sure the original
> coding was intentional.

Well, it didn't make much difference before, since OldestXmin was always
calculated early in the transaction.

--
   Heikki Linnakangas
   EnterpriseDB   http://www.enterprisedb.com


В списке pgsql-patches по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: Recalculating OldestXmin in a long-running vacuum
Следующее
От: Neil Conway
Дата:
Сообщение: Re: TODO improvements