Horton

Re: [Proposal] Allow users to specify multiple tables in VACUUM commands

Alvaro Herrera <alvherre@alvh.no-ip.org>

View thread View on postgr.es
From: Alvaro Herrera <alvherre@alvh.no-ip.org>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: "Bossart, Nathan" <bossartn@amazon.com>, Simon Riggs <simon@2ndquadrant.com>, Michael Paquier <michael.paquier@gmail.com>, Masahiko Sawada <sawada.mshk@gmail.com>, "David G. Johnston" <david.g.johnston@gmail.com>, Robert Haas <robertmhaas@gmail.com>, "pgsql-hackers@postgresql.org" <pgsql-hackers@postgresql.org>
Date: 2017-09-05T21:20:51Z
Lists: pgsql-hackers 
Tom Lane wrote:
> "Bossart, Nathan" <bossartn@amazon.com> writes:
> > On 9/4/17, 10:32 PM, "Simon Riggs" <simon@2ndquadrant.com> wrote:
> >> If we want to keep the code simple we must surely consider whether the
> >> patch has any utility.
> 
> > ... I'd argue that this feels like a natural extension of the
> > VACUUM command, one that I, like others much earlier in this thread,
> > was surprised to learn wasn't supported.
> 
> Yeah.  To me, one big argument for allowing multiple target tables is that
> we allow it for other common utility commands such as TRUNCATE or LOCK
> TABLE.

TRUNCATE has actual an feature behind its multi-table ability: you can
truncate tables linked by FKs that way, and not otherwise.  VACUUM, like
LOCK TABLE, have no such benefit.

(If one is programatically locking multiple tables, it is easier to do
one table per command than many in one command, anyway.)

-- 
Álvaro Herrera                https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

Commits

  1. Allow multiple tables to be specified in one VACUUM or ANALYZE command.

  2. Give a better error for duplicate entries in VACUUM/ANALYZE column list.

  3. Reject ANALYZE commands during VACUUM FULL or another ANALYZE.