New partitioning - some feedback
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!
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.
regards
Mark
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/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]/messages/by-id/CAM-w4HOZ5fPS7GoCTTrW42q01+wPrOWFCnr9H0iDyVTZP2H1CA@mail.gmail.com. And then it came up again
[2]: /messages/by-id/20170406070227.GA2741046@tornado.leadboat.com
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]: /messages/by-id/CAM-w4HOZ5fPS7GoCTTrW42q01+wPrOWFCnr9H0iDyVTZP2H1CA@mail.gmail.com
/messages/by-id/CAM-w4HOZ5fPS7GoCTTrW42q01+wPrOWFCnr9H0iDyVTZP2H1CA@mail.gmail.com
[2]: /messages/by-id/20170406070227.GA2741046@tornado.leadboat.com
/messages/by-id/20170406070227.GA2741046@tornado.leadboat.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On 07/07/17 13:29, Amit Langote wrote:
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.
Yeah, me too (clearly). However if the consensus is that all these
partition tables *must* be shown in \d output, then I'd be happy if they
were identified as such rather than just 'table' (e.g 'partition table').
regards
Mark
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Fri, Jul 07, 2017 at 07:40:55PM +1200, Mark Kirkwood wrote:
On 07/07/17 13:29, Amit Langote wrote:
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.Yeah, me too (clearly). However if the consensus is that all these partition
tables *must* be shown in \d output, then I'd be happy if they were
identified as such rather than just 'table' (e.g 'partition table').
+1.
Or maybe just 'partition' is enough if 'partition table' would widen the
column output unnecessarily.
Michael
--
Michael Banck
Projektleiter / Senior Berater
Tel.: +49 2166 9901-171
Fax: +49 2166 9901-100
Email: michael.banck@credativ.de
credativ GmbH, HRB M�nchengladbach 12080
USt-ID-Nummer: DE204566209
Trompeterallee 108, 41189 M�nchengladbach
Gesch�ftsf�hrung: Dr. Michael Meskes, J�rg Folz, Sascha Heuer
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On 7 July 2017 at 08:54, Michael Banck <michael.banck@credativ.de> wrote:
On Fri, Jul 07, 2017 at 07:40:55PM +1200, Mark Kirkwood wrote:
On 07/07/17 13:29, Amit Langote wrote:
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.Yeah, me too (clearly). However if the consensus is that all these partition
tables *must* be shown in \d output, then I'd be happy if they were
identified as such rather than just 'table' (e.g 'partition table').+1.
+1 to remove partitions from \d display
With 1000 partitions that would just be annoying
--
Simon Riggs http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Fri, Jul 7, 2017 at 3:54 AM, Michael Banck <michael.banck@credativ.de> wrote:
+1.
Or maybe just 'partition' is enough if 'partition table' would widen the
column output unnecessarily.
Internally to the source code, the parent is called a "partitioned
table" and the child is called a "partition". I think we should not
use the term "partition table" because I think it could create
confusion as to which of those two things we're talking about. It
would be reasonable to write "partition" rather than "table" for
partitions, though. We'd probably also need "partition index" (for
indexes on partition) and "foreign partition" (for foreign tables that
are partitions).
I don't have a strong view on whether partitions should be hidden by
default, although I lean slightly against it (say, -0.25). But if we
do decide to hide them by default, then I definitely want an
easy-to-use modifier that overrides that behavior, like being able to
type \d! or whatever to have them included after all.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Robert Haas <robertmhaas@gmail.com> writes:
I don't have a strong view on whether partitions should be hidden by
default, although I lean slightly against it (say, -0.25). But if we
do decide to hide them by default, then I definitely want an
easy-to-use modifier that overrides that behavior, like being able to
type \d! or whatever to have them included after all.
AIUI the user is responsible for DDL on partitions, like say creating
indexes for them? Seems like hiding them is a bad idea given that.
Also, we need to be careful about calling them something very separate
from "table", because that would rouse the need to have duplicate syntax
for every sort of ALTER TABLE and suchlike command that we want to have
be usable with partitions. I think we've largely gone the wrong direction
in that respect with respect to foreign tables and matviews.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On 7 July 2017 at 13:20, Tom Lane <tgl@sss.pgh.pa.us> wrote:
Robert Haas <robertmhaas@gmail.com> writes:
I don't have a strong view on whether partitions should be hidden by
default, although I lean slightly against it (say, -0.25). But if we
do decide to hide them by default, then I definitely want an
easy-to-use modifier that overrides that behavior, like being able to
type \d! or whatever to have them included after all.AIUI the user is responsible for DDL on partitions, like say creating
indexes for them? Seems like hiding them is a bad idea given that.
Also, we need to be careful about calling them something very separate
from "table", because that would rouse the need to have duplicate syntax
for every sort of ALTER TABLE and suchlike command that we want to have
be usable with partitions. I think we've largely gone the wrong direction
in that respect with respect to foreign tables and matviews.
Hmm, "hiding" would not be an accurate description of the proposal. I
would characterize it more as removing extraneous information, since
for a partitioned table seeing 1000 records all with roughly the same
name isn't helpful output from \d
\d would show tables but not partitions
\d <tablename> would show partitions exist and how many
\d+ would show partition details
So the information would be available, just at different levels of
detail, just as we have now for other things.
--
Simon Riggs http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Fri, Jul 7, 2017 at 8:20 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
Robert Haas <robertmhaas@gmail.com> writes:
I don't have a strong view on whether partitions should be hidden by
default, although I lean slightly against it (say, -0.25). But if we
do decide to hide them by default, then I definitely want an
easy-to-use modifier that overrides that behavior, like being able to
type \d! or whatever to have them included after all.AIUI the user is responsible for DDL on partitions, like say creating
indexes for them? Seems like hiding them is a bad idea given that.
Also, we need to be careful about calling them something very separate
from "table", because that would rouse the need to have duplicate syntax
for every sort of ALTER TABLE and suchlike command that we want to have
be usable with partitions. I think we've largely gone the wrong direction
in that respect with respect to foreign tables and matviews.
Well, I'm not sure what other direction we could have taken there, and
I don't think it follows that just because it's labeled differently in
\d output it has to have different SQL syntax.
On the core question of whether they should be hidden, I think the
answer is that it depends on the situation. As Simon says, if people
use partitioning with large numbers of partitions, listing many
nearly-identical partition names clutters up the list to an extent
that makes life quite difficult; I've encountered this as a real
usability problem on actual systems. On the other hand, people with
more modest numbers of partitions (say, 10) might well find it more
convenient to see those names included, because they're legitimate
targets for commands like COMMENT and DROP TABLE and lots of other
things, and somebody might very well find it convenient to be able to
get that with \d rather than \d+ parent_table_name.
As I say, I don't feel hugely strongly about the default behavior, but
I do feel strongly that the idea that only one of the two proposed
behavior is useful is entirely incorrect.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Fri, Jul 07, 2017 at 10:29:26AM +0900, Amit Langote wrote:
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)
Would showing relispartition=tru tables only in \d+ fix this?
Best,
David.
--
David Fetter <david(at)fetter(dot)org> http://fetter.org/
Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter
Skype: davidfetter XMPP: david(dot)fetter(at)gmail(dot)com
Remember to vote!
Consider donating to Postgres: http://www.postgresql.org/about/donate
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On 07/07/17 19:54, Michael Banck wrote:
On Fri, Jul 07, 2017 at 07:40:55PM +1200, Mark Kirkwood wrote:
On 07/07/17 13:29, Amit Langote wrote:
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.Yeah, me too (clearly). However if the consensus is that all these partition
tables *must* be shown in \d output, then I'd be happy if they were
identified as such rather than just 'table' (e.g 'partition table').+1.
Or maybe just 'partition' is enough if 'partition table' would widen the
column output unnecessarily.
Yeah, that is probably better (and 'partition table' is potentially
confusing as Robert pointed out).
Cheers
Mark
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On 2017/07/08 14:12, Mark Kirkwood wrote:
On 07/07/17 19:54, Michael Banck wrote:
On Fri, Jul 07, 2017 at 07:40:55PM +1200, Mark Kirkwood wrote:
On 07/07/17 13:29, Amit Langote wrote:
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.Yeah, me too (clearly). However if the consensus is that all these
partition
tables *must* be shown in \d output, then I'd be happy if they were
identified as such rather than just 'table' (e.g 'partition table').+1.
Or maybe just 'partition' is enough if 'partition table' would widen the
column output unnecessarily.Yeah, that is probably better (and 'partition table' is potentially
confusing as Robert pointed out).
So, it seems at least that showing "partition" as the Type of tables that
are actually partitions is preferable. I created a patch (attached 0001)
that implements that. It makes \d show any relations that have
relispartition = true as of type "partition" or "foreign partition". With
the patch:
create table p (a int) partition by list (a);
-- regular table as partition
create table p1 partition of p for values in (1)
-- foreign table as partition
create foreign data wrapper dummy;
create server dummy foreign data wrapper dummy;
create foreign table p2 partition of p for values in (2) server dummy;
-- partitioned table as partition
create table p3 partition of p for values in (3) partition by list (a);
\d
List of relations
Schema | Name | Type | Owner
--------+------+-------------------+-------
public | p | table | amit
public | p1 | partition | amit
public | p2 | foreign partition | amit
public | p3 | partition | amit
(4 rows)
Also, there seems to be at least some preference for excluding partitions
by default from the \d listing. Attached 0002 implements that. To enable
showing partitions, the patch adds a new modifier '!' to \d (picked '!'
from Robert's email on this thread [1]/messages/by-id/CA+TgmoYNPHFjY+ObFF9=TbX+T6ez1FAU+smGuXeoiOMasDc-0g@mail.gmail.com). With the patch:
\d
List of relations
Schema | Name | Type | Owner
--------+------+-------+-------
public | p | table | amit
(1 row)
\d!
List of relations
Schema | Name | Type | Owner
--------+------+-------------------+-------
public | p | table | amit
public | p1 | partition | amit
public | p2 | foreign partition | amit
public | p3 | partition | amit
(4 rows)
\d!+
List of relations
Schema | Name | Type | Owner | Size | Description
--------+------+-------------------+-------+---------+-------------
public | p | table | amit | 0 bytes |
public | p1 | partition | amit | 0 bytes |
public | p2 | foreign partition | amit | 0 bytes |
public | p3 | partition | amit | 0 bytes |
(4 rows)
Thanks,
Amit
[1]: /messages/by-id/CA+TgmoYNPHFjY+ObFF9=TbX+T6ez1FAU+smGuXeoiOMasDc-0g@mail.gmail.com
/messages/by-id/CA+TgmoYNPHFjY+ObFF9=TbX+T6ez1FAU+smGuXeoiOMasDc-0g@mail.gmail.com
Attachments:
0001-Show-foreign-partition-as-Type-in-d-output.patchtext/plain; charset=UTF-8; name=0001-Show-foreign-partition-as-Type-in-d-output.patchDownload+39-10
0002-Exclude-partitions-by-default-from-the-the-psql-d-li.patchtext/plain; charset=UTF-8; name=0002-Exclude-partitions-by-default-from-the-the-psql-d-li.patchDownload+37-20
On 8 July 2017 at 00:03, David Fetter <david@fetter.org> wrote:
On Fri, Jul 07, 2017 at 10:29:26AM +0900, Amit Langote wrote:
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)Would showing relispartition=tru tables only in \d+ fix this?
<http://www.postgresql.org/mailpref/pgsql-hackers>
I think so.
I'd like to add a flag of some kind to \d column output that marks a table
as having partitions, but I can't think of anything narrow enough and still
useful.
--
Craig Ringer http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
On 2017/07/10 15:32, Craig Ringer wrote:
On 8 July 2017 at 00:03, David Fetter <david@fetter.org> wrote:
On Fri, Jul 07, 2017 at 10:29:26AM +0900, Amit Langote wrote:
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)Would showing relispartition=tru tables only in \d+ fix this?
<http://www.postgresql.org/mailpref/pgsql-hackers>I think so.
I posted a patch upthread which makes \d hide partitions (relispartition =
true relations) and include them if the newly proposed '!' modifier is
specified. The '+' modifier is being used to show additional detail of
relations chosen to be listed at all, so it seemed like a bad idea to
extend its meaning to also dictate whether partitions are to be listed.
We have a separate 'S' modifier to ask to list system objects (which are,
by default hidden), so it made sense to me to add yet another modifier
(aforementioned '!') for partitions.
I'd like to add a flag of some kind to \d column output that marks a table
as having partitions, but I can't think of anything narrow enough and still
useful.
Actually, if \d had shown RELKIND_PARTITIONED_TABLE tables as of Type
"partitioned table", we wouldn't need a separate flag for marking a table
as having partitions. But we've avoided using that term ("partitioned
table") in the error messages and such, so wouldn't perhaps be a good idea
to do that here. But I wonder if we (also) want to distinguish
partitioned tables from regular tables? I understood that there is some
desire for partitions be distinguished when they are listed in the output,
either by default or by using a modifier.
Thanks,
Amit
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Mon, Jul 10, 2017 at 04:15:28PM +0900, Amit Langote wrote:
On 2017/07/10 15:32, Craig Ringer wrote:
On 8 July 2017 at 00:03, David Fetter <david@fetter.org> wrote:
On Fri, Jul 07, 2017 at 10:29:26AM +0900, Amit Langote wrote:
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)Would showing relispartition=tru tables only in \d+ fix this?
<http://www.postgresql.org/mailpref/pgsql-hackers>I think so.
I posted a patch upthread which makes \d hide partitions (relispartition =
true relations) and include them if the newly proposed '!' modifier is
specified. The '+' modifier is being used to show additional detail of
relations chosen to be listed at all, so it seemed like a bad idea to
extend its meaning to also dictate whether partitions are to be listed.
We have a separate 'S' modifier to ask to list system objects (which are,
by default hidden), so it made sense to me to add yet another modifier
(aforementioned '!') for partitions.
We have already made '+' signal "more detail, unspecified," for a lot
of different cases. If partitions are just "more detail" about a
table, which is the direction we've decided to go, it makes sense to
list them under the rubric of '+' rather than inventing yet another
hunk of syntax to psql's already confusing \ commands.
I'd like to add a flag of some kind to \d column output that marks a table
as having partitions, but I can't think of anything narrow enough and still
useful.Actually, if \d had shown RELKIND_PARTITIONED_TABLE tables as of Type
"partitioned table", we wouldn't need a separate flag for marking a table
as having partitions. But we've avoided using that term ("partitioned
table") in the error messages and such, so wouldn't perhaps be a good idea
to do that here. But I wonder if we (also) want to distinguish
partitioned tables from regular tables? I understood that there is some
desire for partitions be distinguished when they are listed in the output,
either by default or by using a modifier.
+1 for showing that they're a different beast.
Best,
David.
--
David Fetter <david(at)fetter(dot)org> http://fetter.org/
Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter
Skype: davidfetter XMPP: david(dot)fetter(at)gmail(dot)com
Remember to vote!
Consider donating to Postgres: http://www.postgresql.org/about/donate
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Mon, Jul 10, 2017 at 2:15 AM, Amit Langote
<Langote_Amit_f8@lab.ntt.co.jp> wrote:
I posted a patch upthread which makes \d hide partitions (relispartition =
true relations) and include them if the newly proposed '!' modifier is
specified. The '+' modifier is being used to show additional detail of
relations chosen to be listed at all, so it seemed like a bad idea to
extend its meaning to also dictate whether partitions are to be listed.
+1. That'd be a mess.
Actually, if \d had shown RELKIND_PARTITIONED_TABLE tables as of Type
"partitioned table", we wouldn't need a separate flag for marking a table
as having partitions.
I think that is false. Whether something is partitioned and whether
it is a partition are independent concerns.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Mon, Jul 10, 2017 at 05:33:34PM -0500, Robert Haas wrote:
On Mon, Jul 10, 2017 at 2:15 AM, Amit Langote
<Langote_Amit_f8@lab.ntt.co.jp> wrote:I posted a patch upthread which makes \d hide partitions
(relispartition = true relations) and include them if the newly
proposed '!' modifier is specified. The '+' modifier is being
used to show additional detail of relations chosen to be listed at
all, so it seemed like a bad idea to extend its meaning to also
dictate whether partitions are to be listed.+1. That'd be a mess.
With utmost respect, it's less messy than adding '!' to the already
way too random and mysterious syntax of psql's \ commands. What
should '\det!' mean? What about '\dT!'?
Actually, if \d had shown RELKIND_PARTITIONED_TABLE tables as of
Type "partitioned table", we wouldn't need a separate flag for
marking a table as having partitions.I think that is false. Whether something is partitioned and whether
it is a partition are independent concerns.
So whatever we land on needs to mention partition_of and
has_partitions. Is that latter just its immediate partitions?
Recursion all the way down? Somewhere in between?
Best,
David.
--
David Fetter <david(at)fetter(dot)org> http://fetter.org/
Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter
Skype: davidfetter XMPP: david(dot)fetter(at)gmail(dot)com
Remember to vote!
Consider donating to Postgres: http://www.postgresql.org/about/donate
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On 10 July 2017 at 23:46, David Fetter <david@fetter.org> wrote:
On Mon, Jul 10, 2017 at 05:33:34PM -0500, Robert Haas wrote:
On Mon, Jul 10, 2017 at 2:15 AM, Amit Langote
<Langote_Amit_f8@lab.ntt.co.jp> wrote:I posted a patch upthread which makes \d hide partitions
(relispartition = true relations) and include them if the newly
proposed '!' modifier is specified. The '+' modifier is being
used to show additional detail of relations chosen to be listed at
all, so it seemed like a bad idea to extend its meaning to also
dictate whether partitions are to be listed.+1. That'd be a mess.
With utmost respect, it's less messy than adding '!' to the already
way too random and mysterious syntax of psql's \ commands. What
should '\det!' mean? What about '\dT!'?
Fwiw as, I believe, the first person to make this complaint I would be
fine with + listing all partitions. Imho adding an orthogonal "!"
would be too much mental overhead for the user.
If you want something different perhaps we can invent ++ for "even
more information" and list partitions only if two plusses are
provided. (I don't think the other way around makes sense since you
might need a way to list permissions and comments without listing
every partition if you're on a system with an unmanageable number of
partitions but you never absolutely need a way to list partitions
without the comments and permissions). At least that doesn't require
the user to learn a new flag and how it interacts with everything
else.
--
greg
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On 2017/07/11 7:33, Robert Haas wrote:
On Mon, Jul 10, 2017 at 2:15 AM, Amit Langote <Langote_Amit_f8@lab.ntt.co.jp> wrote:
Actually, if \d had shown RELKIND_PARTITIONED_TABLE tables as of Type
"partitioned table", we wouldn't need a separate flag for marking a table
as having partitions.I think that is false. Whether something is partitioned and whether
it is a partition are independent concerns.
I meant to speak of RELKIND_PARTITIONED_TABLE tables as having partitions
(although it could be a partition itself too). If based on the relkind,
we had shown their type as "partitioned table" (not just "table"), then we
wouldn't need a separate flag/column in the \d output to distinguish
partitioned tables as being different from regular tables, as Craig seemed
to be proposing.
Since we are going the route of showing relispartition = true relations as
of different type in the \d listing (as "partition"/"foreign partition"),
we might as well go and spell RELKIND_PARTITIONED_TABLE tables as
"partitioned table". But, I'm afraid that it would be a much bigger
change if we don't want to restrict this terminology change to \d listing;
error messages don't bother about distinguishing "partitions"
(relispartition = true) or "partitioned tables"
(RELKIND_PARTITIONED_TABLE), for instance.
Thanks,
Amit
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Also, there seems to be at least some preference
for excluding partitions by default from the \d listing.
As another user of partitions I'll chime in and say that would be very
nice! On the other hand, with pre-10 partitions you do see all the
child tables with `\d`, so showing declarative partitions seems more
consistent with the old functionality.
On the third hand with pre-10 partitions I can put the child tables
into a separate schema to de-clutter `\d`, but I don't see any way to
do that with declarative partitions. Since there is no workaround it
makes it a bit more important for partitions not to be so noisy.
Paul
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
