pgsql: Avoid holding AutovacuumScheduleLock while rechecking table stat

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: pgsql-committers(at)postgresql(dot)org
Subject: pgsql: Avoid holding AutovacuumScheduleLock while rechecking table stat
Date: 2018-03-13 16:28:50
Message-ID: E1evmnC-0000MW-2f@gemulon.postgresql.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-committers

Avoid holding AutovacuumScheduleLock while rechecking table statistics.

In databases with many tables, re-fetching the statistics takes some time,
so that this behavior seriously decreases the available concurrency for
multiple autovac workers. There's discussion afoot about more complete
fixes, but a simple and back-patchable amelioration is to claim the table
and release the lock before rechecking stats. If we find out there's no
longer a reason to process the table, re-taking the lock to un-claim the
table is cheap enough.

(This patch is quite old, but got lost amongst a discussion of more
aggressive fixes. It's not clear when or if such a fix will be
accepted, but in any case it'd be unlikely to get back-patched.
Let's do this now so we have some improvement for the back branches.)

In passing, make the normal un-claim step take AutovacuumScheduleLock
not AutovacuumLock, since that is what is documented to protect the
wi_tableoid field. This wasn't an actual bug in view of the fact that
readers of that field hold both locks, but it creates some concurrency
penalty against operations that need only AutovacuumLock.

Back-patch to all supported versions.

Jeff Janes

Discussion: https://postgr.es/m/26118.1520865816@sss.pgh.pa.us

Branch
------
REL9_5_STABLE

Details
-------
https://git.postgresql.org/pg/commitdiff/231329a17564ecd242b64cfb86209dc6559626d8

Modified Files
--------------
src/backend/postmaster/autovacuum.c | 53 ++++++++++++++++++++++++++-----------
1 file changed, 37 insertions(+), 16 deletions(-)

Browse pgsql-committers by date

  From Date Subject
Next Message Tom Lane 2018-03-13 17:24:54 pgsql: When updating reltuples after ANALYZE, just extrapolate from our
Previous Message Michael Meskes 2018-03-13 15:23:31 pgsql: Set connection back to NULL after freeing it.