Re: [HACKERS] Partitioned tables and relfilenode - Mailing list pgsql-hackers

From Robert Haas
Subject Re: [HACKERS] Partitioned tables and relfilenode
Date
Msg-id CA+TgmoYvpz=LsPtfdXUahJ4VKRLpma9KL_tqRsrpzVFvY7ATJw@mail.gmail.com
Whole thread Raw
In response to Re: [HACKERS] Partitioned tables and relfilenode  (Amit Langote <Langote_Amit_f8@lab.ntt.co.jp>)
Responses Re: [HACKERS] Partitioned tables and relfilenode
List pgsql-hackers
On Fri, Feb 17, 2017 at 1:12 PM, Amit Langote
<Langote_Amit_f8@lab.ntt.co.jp> wrote:
>> I agree.  But, we need to be careful that a database-wide VACUUM or
>> ANALYZE doesn't hit the partitions multiple times, once for the parent
>> and again for each child.  Actually, a database-wide VACUUM should hit
>> each partition individually and do nothing for the parents, but a
>
> This is what would happen even without the patch.  Patch only modifies
> what happens when a partitioned table is specified in the vacuum command.
> It emits a warning:
>
> WARNING: skipping "%s" --- cannot vacuum partitioned tables
>
> It seems both you and Simon agree that instead of this warning, we should
> recurse to process the leaf partitions (ignoring any partitioned tables in
> the hierarchy for which there is nothing to do).  If that's right, I will
> modify the patch to do that.

Yeah, that sounds fine.

>> database-wide ANALYZE should process the parents and do nothing for
>> the children, so that the inheritance statistics get updated.
>
> Currently vacuum() processes the following relations:
>
>         /*
>          * Process all plain relations and materialized views listed in
>          * pg_class
>          */
>
>         while ((tuple = heap_getnext(scan, ForwardScanDirection)) != NULL)
>         {
>             Form_pg_class classForm = (Form_pg_class) GETSTRUCT(tuple);
>
>             if (classForm->relkind != RELKIND_RELATION &&
>                 classForm->relkind != RELKIND_MATVIEW)
>                 continue;
>
> Do you mean that if database-wide analyze is to be run, we should also
> exclude those RELKIND_RELATION relations that are partitions?
>
> So the only way to update a partition's statistics is to directly specify
> it in the command or by autovacuum.

I think if you type:

ANALYZE;

...that should process all partitioned tables and all tables that are
not themselves partitions.  If you type:

ANALYZE name;

...that should ANALYZE that relation, whatever it is.  If it's a
partitioned table, it should recurse.

> Truncate already recurses to partitions by way of inheritance recursion
> that's already in place.  The patch simply teaches ExecuteTruncate() to
> ignore partitioned tables when we get to the part where relfilenodes are
> manipulated.

Oh, OK.  That seems fine.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company



pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: [HACKERS] Replication vs. float timestamps is a disaster
Next
From: Robert Haas
Date:
Subject: Re: [HACKERS] SCRAM authentication, take three