Re: A few new options for vacuumdb - Mailing list pgsql-hackers

From Michael Paquier
Subject Re: A few new options for vacuumdb
Date
Msg-id 20190129023526.GA3121@paquier.xyz
Whole thread Raw
In response to Re: A few new options for vacuumdb  ("Bossart, Nathan" <bossartn@amazon.com>)
Responses Re: A few new options for vacuumdb  ("Bossart, Nathan" <bossartn@amazon.com>)
List 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

Attachment

pgsql-hackers by date:

Previous
From: Andreas Karlsson
Date:
Subject: Re: Covering GiST indexes
Next
From: Andreas Karlsson
Date:
Subject: Re: Early WIP/PoC for inlining CTEs