From: | Masahiko Sawada <masahiko(dot)sawada(at)2ndquadrant(dot)com> |
---|---|
To: | Michael Paquier <michael(at)paquier(dot)xyz> |
Cc: | Justin Pryzby <pryzby(at)telsasoft(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: [PATCH] Tab completion for VACUUM of partitioned tables |
Date: | 2020-07-29 09:41:16 |
Message-ID: | CA+fd4k5EWeSDnLre_XRzusay3prDJPATHvhzXq-Y+tSqcP1G2g@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Wed, 29 Jul 2020 at 15:21, Michael Paquier <michael(at)paquier(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Amul Sul | 2020-07-29 10:35:00 | Re: [Patch] ALTER SYSTEM READ ONLY |
Previous Message | Martijn van Oosterhout | 2020-07-29 09:24:57 | IDEA: pg_stat_statements tracking utility statements by tag? |