Postgres Pro
Downloads
Home   >   mailing lists

Re: [PATCH] Tab completion for VACUUM of partitioned tables - Mailing list pgsql-hackers

From Masahiko Sawada
Subject Re: [PATCH] Tab completion for VACUUM of partitioned tables
Date
Msg-id CA+fd4k5EWeSDnLre_XRzusay3prDJPATHvhzXq-Y+tSqcP1G2g@mail.gmail.com
Whole thread Raw
In response to Re: [PATCH] Tab completion for VACUUM of partitioned tables  (Michael Paquier <michael@paquier.xyz>)
Responses Re: [PATCH] Tab completion for VACUUM of partitioned tables  (Michael Paquier <michael@paquier.xyz>)
List pgsql-hackers
Tree view 
On Wed, 29 Jul 2020 at 15:21, Michael Paquier <michael@paquier.xyz> wrote:
>
> On Wed, Jul 29, 2020 at 01:27:07PM +0900, Masahiko Sawada wrote:
> > Good catch. The patch looks good to me.
>
> While this patch is logically correct.  I think that we should try to
> not increase more the number of queries used to scan pg_class
> depending on a list of relkinds.  For example, did you notice that
> your new Query_for_list_of_vacuumables becomes the same query as
> Query_for_list_of_indexables?

Oh, I didn't realize that.

Looking at target relation kinds for operations in-depth, I think that
the relation list for index creation and the relation list for vacuum
is different.

Query_for_list_of_indexables should search for:

RELKIND_RELATION
RELKIND_PARTITIONED_TABLE
RELKIND_MATVIEW

whereas Query_for_list_of_vacuumables should search for:

RELKIND_RELATION
RELKIND_PARTITIONED_TABLE
RELKIND_MATVIEW
RELKIND_TOASTVALUE

Also, Query_for_list_of_clusterables is further different from the
above two lists. It should search for:

RELKIND_RELATION
RELKIND_MATVIEW
RELKIND_TOASTVALUE

Regards,

-- 
Masahiko Sawada            http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

pgsql-hackers by date:

Previous
From: Martijn van Oosterhout
Date:
Subject: IDEA: pg_stat_statements tracking utility statements by tag?
Next
From: Amul Sul
Date:
Subject: Re: [Patch] ALTER SYSTEM READ ONLY