| From: | Heikki Linnakangas <heikki(at)enterprisedb(dot)com> |
|---|---|
| To: | Heikki Linnakangas <heikki(at)enterprisedb(dot)com>, pgsql-patches(at)postgresql(dot)org, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Bruce Momjian <bruce(at)momjian(dot)us>, Gregory Stark <gsstark(at)mit(dot)edu>, ITAGAKI Takahiro <itagaki(dot)takahiro(at)oss(dot)ntt(dot)co(dot)jp> |
| Subject: | Re: Recalculating OldestXmin in a long-running vacuum |
| Date: | 2007-03-13 12:36:58 |
| Message-ID: | 45F69AEA.7050206@enterprisedb.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | 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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Heikki Linnakangas | 2007-03-13 12:38:31 | Re: Recalculating OldestXmin in a long-running vacuum |
| Previous Message | Alvaro Herrera | 2007-03-13 12:27:41 | Re: Recalculating OldestXmin in a long-running vacuum |