Re: new vacuum is slower for small tables

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: "Pavel Stehule" <pavel(dot)stehule(at)gmail(dot)com>
Cc: "Heikki Linnakangas" <heikki(dot)linnakangas(at)enterprisedb(dot)com>, "postgres hackers" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: new vacuum is slower for small tables
Date: 2008-12-08 20:20:34
Message-ID: 513.1228767634@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

"Pavel Stehule" <pavel(dot)stehule(at)gmail(dot)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.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2008-12-08 20:45:58 Re: [COMMITTERS] pgsql: Properly unregister OpenSSL callbacks when libpq is done with
Previous Message Emmanuel Cecchet 2008-12-08 19:47:12 Re: Transactions and temp tables