Re: new vacuum is slower for small tables - Mailing list pgsql-hackers

From Bruce Momjian
Subject Re: new vacuum is slower for small tables
Date
Msg-id 200901201731.n0KHVoN07389@momjian.us
Whole thread Raw
In response to Re: new vacuum is slower for small tables  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
Tom Lane wrote:
> "Pavel Stehule" <pavel.stehule@gmail.com> writes:
> > It's strange, when I repeat tests, I get usually times about 10 ms,
> > but cca cca every 5 test it is about 2ms
> 
> Hmm.  The theory I'd developed for what I see here is that the "slow"
> timings correspond to when the pgstat code decides it needs a new stats
> file (and so it has to signal the stats collector and wait for the file
> to show up).  The "fast" timings occur if the existing stats file is
> considered fresh enough to re-use.  Hence, it's "fast" if you re-execute
> the VACUUM within half a second of the previous one, else slow.  I can't
> tell if that's the same thing you see or not.
> 
> Now that we have the flexibility to allow different levels of stats
> stale-ness for different callers, I wonder whether it wouldn't be okay
> to let pgstat_vacuum_stat work with quite stale files, eg up to a minute
> or so.

Are we doing anything on this?

--  Bruce Momjian  <bruce@momjian.us>        http://momjian.us EnterpriseDB
http://enterprisedb.com
 + If your life is a hard drive, Christ can be your backup. +


pgsql-hackers by date:

Previous
From: Heikki Linnakangas
Date:
Subject: Re: visibility maps
Next
From: Peter Eisentraut
Date:
Subject: Re: is 8.4 array_agg() supposed to work with array values?