Re: New partitioning - some feedback

From: Amit Langote <Langote_Amit_f8(at)lab(dot)ntt(dot)co(dot)jp>
To: Mark Kirkwood <mark(dot)kirkwood(at)catalyst(dot)net(dot)nz>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: New partitioning - some feedback
Date: 2017-07-07 01:29:26
Message-ID: aa0d3305-8725-67c9-d42b-adf1568ecc2c@lab.ntt.co.jp
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi Mark,

On 2017/07/07 9:02, Mark Kirkwood wrote:
> I've been trying out the new partitioning in version 10. Firstly, I must
> say this is excellent - so much nicer than the old inheritance based method!

Thanks. :)

> My only niggle is the display of partitioned tables via \d etc. e.g:
>
> part=# \d
> List of relations
> Schema | Name | Type | Owner
> --------+----------------------+-------+----------
> public | date_fact | table | postgres
> public | date_fact_201705 | table | postgres
> public | date_fact_201706 | table | postgres
> public | date_fact_20170601 | table | postgres
> public | date_fact_2017060100 | table | postgres
> public | date_fact_201707 | table | postgres
> public | date_fact_rest | table | postgres
> (7 rows)
>
> Now it can be inferred from the names that date_fact is a partitioned
> table and the various date_fact_dddd are its partitions - but \d is not
> providing any hints of this. The more detailed individual describe is fine:
>
> part=# \d date_fact
> Table "public.date_fact"
> Column | Type | Collation | Nullable | Default
> --------+--------------------------+-----------+----------+---------
> id | integer | | not null |
> dte | timestamp with time zone | | not null |
> val | integer | | not null |
> Partition key: RANGE (dte)
> Number of partitions: 6 (Use \d+ to list them.)
>
> I'd prefer *not* to see a table and its partitions all intermixed in the
> same display (especially with nothing indicating which are partitions) -
> as this will make for unwieldy long lists when tables have many
> partitions. Also it would be good if the 'main' partitioned table and its
> 'partitions' showed up as a different type in some way.
> I note the they do in pg_class:
>
> part=# SELECT relname,relkind,relispartition FROM pg_class WHERE relname
> LIKE 'date_fact%';
> relname | relkind | relispartition
> ----------------------+---------+----------------
> date_fact | p | f
> date_fact_201705 | r | t
> date_fact_201706 | r | t
> date_fact_20170601 | r | t
> date_fact_2017060100 | r | t
> date_fact_201707 | r | t
> date_fact_rest | r | t
> (7 rows)
>
> ...so it looks to be possible to hide the partitions from the main display
> and/or mark them as such. Now I realize that making this comment now that
> beta is out is a bit annoying - apologies, but I think seeing a huge list
> of 'tables' is going to make \d frustrating for folk doing partitioning.

Someone complained about this awhile back [1]. And then it came up again
[2], where Noah appeared to take a stance that partitions should be
visible in views / output of commands that list "tables".

Although I too tend to prefer not filling up the \d output space by
listing partitions (pg_class.relispartition = true relations), there
wasn't perhaps enough push for creating a patch for that. If some
committer is willing to consider such a patch, I can make one.

Thanks,
Amit

[1]
https://www.postgresql.org/message-id/CAM-w4HOZ5fPS7GoCTTrW42q01%2BwPrOWFCnr9H0iDyVTZP2H1CA%40mail.gmail.com

[2]
https://www.postgresql.org/message-id/20170406070227.GA2741046%40tornado.leadboat.com

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Michael Paquier 2017-07-07 02:19:24 Re: Error while copying a large file in pg_rewind
Previous Message Thomas Munro 2017-07-07 01:06:46 Re: Out of date comment in predicate.c