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

From: "Bossart, Nathan" <bossartn(at)amazon(dot)com>
To: Michael Paquier <michael(dot)paquier(at)gmail(dot)com>
Cc: 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>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Subject: Re: [Proposal] Allow users to specify multiple tables in VACUUM commands
Date: 2017-09-11 05:05:43
Views: Raw Message | Whole Thread | Download mbox
Lists: pgsql-hackers

On 9/9/17, 7:28 AM, "Michael Paquier" <michael(dot)paquier(at)gmail(dot)com> wrote:
> In the duplicate patch, it seems to me that you can save one lookup at
> the list of VacuumRelation items by checking for column duplicates
> after checking that all the columns are defined. If you put the
> duplicate check before closing the relation you can also use the
> schema name associated with the Relation.

I've made these changes in v4 of the duplicate patch.

> + if (i == InvalidAttrNumber)
> + ereport(ERROR,
> + errmsg("column \"%s\" of relation \"%s\" does not exist",
> + col, RelationGetRelationName(rel))));
> This could use the schema name unconditionally as you hold a Relation
> here, using RelationGetNamespace().

This is added in v16 of the main patch.

> So if the relation is analyzed but skipped, we would have no idea that
> it actually got skipped because there are no reports about it. That's
> not really user-friendly. I am wondering if we should not instead have
> analyze_rel also enforce the presence of a RangeVar, and adding an
> assert at the beginning of the function to undertline that, and also
> do the same for vacuum(). It would make things also consistent with
> vacuum() which now implies on HEAD that a RangeVar *must* be
> specified.

I've made these changes in v16 of the main patch.


Attachment Content-Type Size
vacuum_multiple_tables_v16.patch application/octet-stream 34.0 KB
error_on_duplicate_columns_in_analyze_v4.patch application/octet-stream 6.1 KB

In response to


Browse pgsql-hackers by date

  From Date Subject
Next Message Amit Langote 2017-09-11 06:46:59 Re: Partition-wise join for join between (declaratively) partitioned tables
Previous Message Michael Paquier 2017-09-11 02:37:39 Re: [JDBC] Channel binding support for SCRAM-SHA-256