Re: Recalculating OldestXmin in a long-running vacuum

Поиск
Список
Период
Сортировка
От Bruce Momjian
Тема Re: Recalculating OldestXmin in a long-running vacuum
Дата
Msg-id 200703271602.l2RG2kX09725@momjian.us
обсуждение исходный текст
Ответ на Re: Recalculating OldestXmin in a long-running vacuum  (Heikki Linnakangas <heikki@enterprisedb.com>)
Ответы Re: Recalculating OldestXmin in a long-running vacuum  (Heikki Linnakangas <heikki@enterprisedb.com>)
Список pgsql-patches
Heikki Linnakangas wrote:
> 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.

So are you stopping work on the patch?  I assume so.

--
  Bruce Momjian  <bruce@momjian.us>          http://momjian.us
  EnterpriseDB                               http://www.enterprisedb.com

  + If your life is a hard drive, Christ can be your backup. +

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

Предыдущее
От: Bruce Momjian
Дата:
Сообщение: Re: Warning about LISTEN names
Следующее
От: "Simon Riggs"
Дата:
Сообщение: Re: Fast CLUSTER