| From: | Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | "Bossart, Nathan" <bossartn(at)amazon(dot)com>, Simon Riggs <simon(at)2ndquadrant(dot)com>, Michael Paquier <michael(dot)paquier(at)gmail(dot)com>, Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com>, "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: [Proposal] Allow users to specify multiple tables in VACUUM commands |
| Date: | 2017-09-05 21:20:51 |
| Message-ID: | 20170905212051.34rq3nlm7eox6svb@alvherre.pgsql |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Tom Lane wrote:
> "Bossart, Nathan" <bossartn(at)amazon(dot)com> writes:
> > On 9/4/17, 10:32 PM, "Simon Riggs" <simon(at)2ndquadrant(dot)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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Michael Paquier | 2017-09-05 22:10:44 | Re: Proposal for changes to recovery.conf API |
| Previous Message | Tom Lane | 2017-09-05 20:02:14 | Re: Replacing lfirst() with lfirst_node() appropriately in planner.c |