| From: | Michael Paquier <michael(at)paquier(dot)xyz> |
|---|---|
| To: | Amit Langote <Langote_Amit_f8(at)lab(dot)ntt(dot)co(dot)jp> |
| Cc: | Thomas Munro <thomas(dot)munro(at)enterprisedb(dot)com>, Jesper Pedersen <jesper(dot)pedersen(at)redhat(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, Jeevan Ladhe <jeevan(dot)ladhe(at)enterprisedb(dot)com>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: partition tree inspection functions |
| Date: | 2018-10-01 06:27:43 |
| Message-ID: | 20181001062743.GA11712@paquier.xyz |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Mon, Oct 01, 2018 at 03:16:32PM +0900, Amit Langote wrote:
> I wasn't able to respond to some of issues that Jesper brought up with the
> approach taken by the latest patch whereby there is no separate
> pg_partition_level function. He said that such a function would be useful
> to get the information about the individual leaf partitions, but I was no
> longer sure of providing such a function separately.
Perhaps that could be debated separately as well? From what I can see
what's available would unlock the psql patch which would like to add
support for \dP, or show the size of partitions more easily. I am also
not completely sure that I see the use-case for pg_partition_level or
even pg_partition_root_parent as usually in their schemas users append
rather similar relation names to the parent and the children. Or
perhaps not?
--
Michael
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Michael Paquier | 2018-10-01 06:30:06 | Re: Sample values for pg_stat_statements |
| Previous Message | Michael Paquier | 2018-10-01 06:19:17 | Re: libpq should append auth failures, not overwrite |