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
|
Список | 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 по дате отправления: