Horton

Re: PROC_IN_ANALYZE stillborn 13 years ago

Tom Lane <tgl@sss.pgh.pa.us>

View thread View on postgr.es
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Robert Haas <robertmhaas@gmail.com>
Cc: Andres Freund <andres@anarazel.de>, Alvaro Herrera <alvherre@2ndquadrant.com>, James Coleman <jtc331@gmail.com>, pgsql-hackers <pgsql-hackers@lists.postgresql.org>, Simon Riggs <simon@2ndquadrant.com>
Date: 2020-08-06T19:11:27Z
Lists: pgsql-hackers 
Robert Haas <robertmhaas@gmail.com> writes:
> Not to get too far from the proposal on the table of just removing
> something that's been unused for a really long time, which stands on
> its own merits, but if a particular ANALYZE doesn't invoke any
> user-defined functions and isn't run inside a transaction, could we
> skip acquiring a snapshot altogether? That's an extremely common case,
> though by no means universal.

I'm inclined to think not.

(1) Without a snapshot it's hard to make any non-bogus decisions about
which tuples are live and which are dead.  Admittedly, with Simon's
proposal the final totals would be spongy anyhow, but at least the
individual decisions produce meaningful answers.

(2) I'm pretty sure there are places in the system that assume that any
reader of a table is using an MVCC snapshot.  For instance, didn't you
introduce some such assumptions along with or just after getting rid of
SnapshotNow for catalog scans?

			regards, tom lane

Commits

  1. Call out vacuum considerations in create index docs

  2. Document concurrent indexes waiting on each other

  3. snapshot scalability: Don't compute global horizons while building snapshots.

  4. Remove PROC_IN_ANALYZE and derived flags

  5. Improve performance of get_actual_variable_range with recently-dead tuples.