Re: [HACKERS] dropping partitioned tables without CASCADE - Mailing list pgsql-hackers

From Ashutosh Bapat
Subject Re: [HACKERS] dropping partitioned tables without CASCADE
Date
Msg-id CAFjFpRfJ+xQwqLPfCeQ+MnHKu13nNiHXAAr4sM4zznEkH4DTFw@mail.gmail.com
Whole thread Raw
In response to Re: [HACKERS] dropping partitioned tables without CASCADE  (Simon Riggs <simon@2ndquadrant.com>)
Responses Re: [HACKERS] dropping partitioned tables without CASCADE  (Simon Riggs <simon@2ndquadrant.com>)
List pgsql-hackers
On Mon, Mar 6, 2017 at 8:35 AM, Simon Riggs <simon@2ndquadrant.com> wrote:
> On 6 March 2017 at 00:51, Amit Langote <Langote_Amit_f8@lab.ntt.co.jp> wrote:
>> On 2017/03/05 16:20, Simon Riggs wrote:
>>> I notice also that
>>>   \d+ <tablename>
>>> does not show which partitions have subpartitions.
>>
>> Do you mean showing just whether a partition is itself partitioned or
>> showing its partitions and so on (because those partitions may themselves
>> be partitioned)?  Maybe, we could do the former.
>
> I think \d+ should show the full information, in some form.

For a multi-level inheritance hierarchy, we don't show children which
are further inherited. Same behaviour has been carried over to
partitioning. I don't say that that's good or bad.

Given the recursive structure of partitioned tables, it looks readable
and manageable to print only the direct partitions in \d+. May be we
want to indicate the partitions that are further partitioned. If user
wants information about partitioned partitions, s/he can execute \d+
on the partition, repeating this process to any desired level. This
would work well in the interactive mode, keeping the output of \d+
manageable. Further someone writing a script to consume \d+ output of
a multi-level partitioned table, can code the above process in a
script.

Thinking about how to display partition which are further partitioned,
there are two options. Assume a partitioned table t1 with partitions
t1p1, which is further partitioned and t1p2. One could display \d+ t1
as

\d+ t1                                   Table "public.t1"Column |  Type   | Collation | Nullable | Default | Storage |
Stats
target | Description
--------+---------+-----------+----------+---------+---------+--------------+-------------a      | integer |
|not null |         | plain   |              |
 
Partition key: RANGE (a)
Partitions: t1p1 FOR VALUES FROM (0) TO (100), HAS PARTITIONS           t1p2 FOR VALUES FROM (100) TO (200)

OR

\d+ t1                                   Table "public.t1"Column |  Type   | Collation | Nullable | Default | Storage |
Stats
target | Description
--------+---------+-----------+----------+---------+---------+--------------+-------------a      | integer |
|not null |         | plain   |              |
 
Partition key: RANGE (a)
Partitions: t1p1 FOR VALUES FROM (0) TO (100), PARTITION BY LIST(a)           t1p2 FOR VALUES FROM (100) TO (200)

To me the first option looks fine. If the user is interested in
looking at the subpartitioned in any case s/he will have to execute
\d+. So beyond indicating that a partition has subpartitions, what
other information to include is debatable, given that \d+ on that
partition is going to print it anyway.
-- 
Best Wishes,
Ashutosh Bapat
EnterpriseDB Corporation
The Postgres Database Company



pgsql-hackers by date:

Previous
From: Yugo Nagata
Date:
Subject: Re: [HACKERS] Report the number of skipped frozen pages by manualVACUUM
Next
From: Ashutosh Bapat
Date:
Subject: Re: [HACKERS] Print correct startup cost for the group aggregate.