Re: Concurrent VACUUM and ANALYZE

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: "Jonah H(dot) Harris" <jonah(dot)harris(at)gmail(dot)com>
Cc: "Postgres Hackers" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Concurrent VACUUM and ANALYZE
Date: 2008-07-21 23:59:01
Message-ID: 19487.1216684741@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

"Jonah H. Harris" <jonah(dot)harris(at)gmail(dot)com> writes:
> Because we wouldn't want multiple ANALYZEs running on the same table,
> changing the lock back to an AccessShareLock doesn't sound like a
> solution.

It flat will not work. We used to do it that way, and it didn't
(search for "tuple concurrently updated" in the archives).

> However, what are the thoughts around creating another,
> more-specific lock? Perhaps something like ShareUpdateAnalysisLock?

The general overhead involved in a whole new lock type is high enough
that I would resist taking this path. (It's certainly a lot more than
adding an entry to one enum someplace --- offhand I can name docs and
grammar as important issues. And no you don't get to have a hidden lock
type that no one can see.)

Also, as Alvaro points out, it's far from clear that concurrent VACUUM
and ANALYZE is as safe as you think --- they both want to write the same
fields in pg_class.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Jonah H. Harris 2008-07-22 01:29:20 Re: Concurrent VACUUM and ANALYZE
Previous Message Tom Lane 2008-07-21 23:38:55 Re: Load spikes on 8.1.11