Re: Recalculating OldestXmin in a long-running vacuum - Mailing list pgsql-patches

From Bruce Momjian
Subject Re: Recalculating OldestXmin in a long-running vacuum
Date
Msg-id 200703271602.l2RG2kX09725@momjian.us
Whole thread Raw
In response to Re: Recalculating OldestXmin in a long-running vacuum  (Heikki Linnakangas <heikki@enterprisedb.com>)
Responses Re: Recalculating OldestXmin in a long-running vacuum
List 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 by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: Warning about LISTEN names
Next
From: "Simon Riggs"
Date:
Subject: Re: Fast CLUSTER