On Mon, Aug 7, 2017 at 11:18 AM, Ashutosh Bapat
<ashutosh.bapat@enterprisedb.com> wrote:
>>
>> One objection to this line of attack is that there might be a good
>> case for locking only the partitioned inheritors first and then going
>> back and locking the leaf nodes in a second pass, or even only when
>> required for a particular row. However, that doesn't require putting
>> everything in bound order - it only requires moving the partitioned
>> children to the beginning of the list. And I think rather than having
>> new logic for that, we should teach find_inheritance_children() to do
>> that directly. I have a feeling Ashutosh is going to cringe at this
>> suggestion, but my idea is to do this by denormalizing: add a column
>> to pg_inherits indicating whether the child is of
>> RELKIND_PARTITIONED_TABLE. Then, when find_inheritance_children scans
>> pg_inherits, it can pull that flag out for free along with the
>> relation OID, and qsort() first by the flag and then by the OID. It
>> can also return the number of initial elements of its return value
>> which have that flag set.
>
> I am always uncomfortable, when we save the same information in two
> places without having a way to make sure that they are in sync. That
> means we have to add explicit code to make sure that that information
> is kept in sync. Somebody forgetting to add that code wherever
> necessary means we have contradictory information persisted in the
> databases without an idea of which of them is correct. Not necessarily
> in this case, but usually it is an indication of something going wrong
> with the way schema is designed. May be it's better to use your idea
> of using get_rel_relkind() or find a way to check that the flag is in
> sync with the relkind, like when building the relcache.
Said all that, I think we will use this code quite often and so the
performance benefits by replicating the information are worth the
trouble of maintaining code to sync and check the duplicate
information.
--
Best Wishes,
Ashutosh Bapat
EnterpriseDB Corporation
The Postgres Database Company