Re: partition tree inspection functions

From: Amit Langote <Langote_Amit_f8(at)lab(dot)ntt(dot)co(dot)jp>
To: jesper(dot)pedersen(at)redhat(dot)com
Cc: Michael Paquier <michael(at)paquier(dot)xyz>, 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-07-27 02:33:36
Message-ID: 9f371b71-7b4f-b51c-323c-ca62c4a4ffed@lab.ntt.co.jp
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi Jesper,

Thanks for the quick feedback.

On 2018/07/27 1:30, Jesper Pedersen wrote:
> On 07/26/2018 04:47 AM, Amit Langote wrote:
>> Further, I've added a pg_partition_level that returns the level of a
>> partition in the partition tree wrt to the root of the *whole* partition
>> tree.  But maybe we want this function to accept one more argument,
>> 'rootoid', the OID of the root table against which to measure the level?
>
> I don't think that is needed, or it should at least be an optional parameter.

Optional parameter sounds good, so made it get_partition_level(regclass [
, regclass ]) in the updated patch. Although, adding that argument is not
without possible surprises its result might evoke. Like, what happens if
you try to find the level of the root table by passing a leaf partition
oid for the root table argument, or pass a totally unrelated table for the
root table argument. For now, I've made the function return 0 for such cases.

>> OK, I fixed it to return just the count of leaf partitions and renamed it
>> as such (pg_partition_children_leaf_count), but wonder if it's been made
>> redundant by the addition of pg_partition_leaf_children.
>>
>
> I think with pg_partition_leaf_children that we don't need the _count
> method, called pg_partition_tree_leaf_count in the docs, as we can just do
> a COUNT().

Ah, okay. Removed pg_partition_tree_leaf_count.

Thanks,
Amit

Attachment Content-Type Size
v6-0001-Add-assorted-partition-reporting-functions.patch text/plain 27.2 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Geoghegan 2018-07-27 02:35:56 Re: Deprecating, and scheduling removal of, pg_dump's tar format.
Previous Message Michael Paquier 2018-07-27 02:33:30 Re: Deprecating, and scheduling removal of, pg_dump's tar format.