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

On 9/21/17, 9:55 PM, "Michael Paquier" <michael(dot)paquier(at)gmail(dot)com> wrote:
> I still think that ExecVacuum() should pass a list of VacuumRelation
> objects to vacuum(), and get_rel_oids() should take in input a list,
> and return a completed lists. This way the decision-making of doing
> everything in the same transaction should happens once in vacuum().
> And actually, if several relations are defined with VACUUM, your patch
> would not use one transaction per table as use_own_xacts would be set
> to false. I think that Tom meant that relations whose processed has
> finished have to be committed immediately. Per your patch, the commit
> happens once all relations are committed.

Sorry, I must have misunderstood. I've attached an updated patch that
looks more like what you described. I also cleaned up the test cases
a bit.

IIUC the only time use_own_xacts will be false is when we are only
doing ANALYZE and at least one of the following is true:

1. We are in a transaction block.
2. We are processing only one relation.

From the code, it appears that vacuum_rel() always starts and commits a
new transaction for each relation:

* vacuum_rel expects to be entered with no transaction active; it will
* start and commit its own transaction. But we are called by an SQL

So, by ensuring that get_rel_oids() returns a list whenever multiple
tables are specified, we are making sure that commands like

ANALYZE table1, table2, table3;

create transactions for each processed relation (as long as they are
not inside a transaction block). I suppose the alternative would be
to call vacuum() for each relation and to remove the restriction that
we must be processing more than one relation for use_own_xacts to be
true.

Am I understanding this correctly?

Nathan