From: | Michael Paquier <michael(at)paquier(dot)xyz> |
---|---|
To: | Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com> |
Cc: | Amit Langote <Langote_Amit_f8(at)lab(dot)ntt(dot)co(dot)jp>, mathias(at)brossard(dot)org, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: ToDo: show size of partitioned table |
Date: | 2018-11-20 07:50:31 |
Message-ID: | 20181120075031.GM4400@paquier.xyz |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Mon, Nov 05, 2018 at 11:43:16AM +0100, Pavel Stehule wrote:
> should be fixed now.
Here are some notes on the last version.
+ " FROM pg_inherits i\n"
Missing schema qualification.
+ case 'P':
+ if (cmd[2] == 'i')
+ success = listPartitions(pattern, show_verbose,
true, false);
+ else if (cmd[2] == 't')
+ success = listPartitions(pattern, show_verbose,
false, true);
+ else if (cmd[2] == '+' || cmd[2] == '\0')
+ success = listPartitions(pattern, show_verbose,
false, false);
+ else
+ status = PSQL_CMD_UNKNOWN;
+ break;
The style is heavy. Perhaps it would be cleaner to have a
switch/case.. Not a big deal visibly. show_indexes is true only if the
subcommand is 'i'. show_tables is true only if the subcommand is 't'.
Using "\dP" with a pattern matching a partitioned index should show a
partitioned index, no? As far as I know, a partitioned relation can be
either an index or a table.
Testing the feature, \dP shows all partitioned relations, still does not
show the relationship when multiple levels are used. Could it make
sense to also show the direct parent of a partitioned table when
verbose mode is used?
Could it be possible to have tests for \dP, \dPi and \dPt with matching
patterns? You could just place that in one of the existing tests where
there are partitioned tables and indexes.
--
Michael
From | Date | Subject | |
---|---|---|---|
Next Message | John Naylor | 2018-11-20 08:12:22 | Re: WIP: Avoid creation of the free space map for small tables |
Previous Message | Amit Langote | 2018-11-20 07:47:54 | Re: Regarding performance regression on specific query |