Re: Recalculating OldestXmin in a long-running vacuum

Поиск
Список
Период
Сортировка
От Heikki Linnakangas
Тема Re: Recalculating OldestXmin in a long-running vacuum
Дата
Msg-id 45F69AEA.7050206@enterprisedb.com
обсуждение исходный текст
Ответ на Re: Recalculating OldestXmin in a long-running vacuum  (Alvaro Herrera <alvherre@commandprompt.com>)
Ответы Re: Recalculating OldestXmin in a long-running vacuum  (Heikki Linnakangas <heikki@enterprisedb.com>)
Re: Recalculating OldestXmin in a long-running vacuum  (Bruce Momjian <bruce@momjian.us>)
Список pgsql-patches
Alvaro Herrera wrote:
> Heikki Linnakangas wrote:
>
>> I ran two 24h test runs with DBT-2, one with the patch and one without.
>> To get comparable, predictable results, I turned autovacuum off and run
>> a manual vacuum in a loop on the stock-table alone.
>>
>> As expected, the steady-state of the stock table is smaller with the
>> patch. But only by ~2%, that's slightly less than I expected.
>>
>> But what surprises me is that response times went up a with the patch. I
>> don't know why.
>
> Maybe because of increased contention of ProcArrayLock?  (I assume you
> are using that, althought I haven't seen the patch)

I am, but I doubt that's it. The response times are dominated by I/O, so
any increase in lock contention would hardly show up. And the patch is
only adding one GetOldestXmin call every 1000 scanned pages, which is
nothing compared to the thousands of GetSnapshot calls the normal
transactions are issuing per minute.

The patch must have changed the I/O pattern in some subtle way.

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

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

Предыдущее
От: Alvaro Herrera
Дата:
Сообщение: Re: Recalculating OldestXmin in a long-running vacuum
Следующее
От: Heikki Linnakangas
Дата:
Сообщение: Re: Recalculating OldestXmin in a long-running vacuum