Re: A few new options for vacuumdb

From: Michael Paquier <michael(at)paquier(dot)xyz>
To: "Bossart, Nathan" <bossartn(at)amazon(dot)com>
Cc: Masahiko Sawada <sawada(dot)mshk(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: A few new options for vacuumdb
Date: 2019-01-29 02:35:26
Message-ID: 20190129023526.GA3121@paquier.xyz
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Mon, Jan 28, 2019 at 09:58:17PM +0000, Bossart, Nathan wrote:
> Yes, this simplifies the code quite a bit. I did it this way in
> v6.

Thanks for the quick update. Things could have been made a bit more
simple by just using a for loop instead of while, even if the table
list can be NULL for database-wide operations (perhaps that's a matter
of taste..). prepare_vacuum_command() could be simplified further by
using the server version instead of the full connection string. The
comments at the top of the routine were not properly updated either,
and the last portion appending the relation name just needs one
appendPQExpBuffer() call instead of three separate calls. PQclear()
could have been moved closer to where all the query results have been
consumed, to make the whole more consistent.

Anyway, patches 1 and 2 have been merged, and committed after some
cleanup and adjustments. Patch 3 gets much easier now.

- " ON c.relnamespace OPERATOR(pg_catalog.=) ns.oid\n");
+ " ON c.relnamespace OPERATOR(pg_catalog.=) ns.oid\n"
+ " LEFT JOIN pg_catalog.pg_class t"
+ " ON c.reltoastrelid OPERATOR(pg_catalog.=) t.oid\n");
Why do need this part?
--
Michael

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Andreas Karlsson 2019-01-29 02:36:24 Re: Early WIP/PoC for inlining CTEs
Previous Message Andreas Karlsson 2019-01-29 02:32:34 Re: Covering GiST indexes