On Tue, Jun 12, 2018 at 12:25 PM, Tom Lane <t...@sss.pgh.pa.us> wrote:
> Robert Haas <robertmh...@gmail.com> writes:
>> On Mon, Jun 11, 2018 at 6:24 PM, Tom Lane <t...@sss.pgh.pa.us> wrote:
>>> Not sure about a good fix for this. It seems annoying to copy the
>>> rel's whole partkey data structure into query-local storage, but
>>> I'm not sure we have any choice. On the bright side, there might
>>> be an opportunity to get rid of repeated runtime fmgr_info lookups
>>> in cross-type comparison situations.
>> Is this the same issue I raised in
>> or a similar issue that creeps up at execution time?
> Well, it's related to that: *if* we held the relcache entry open for
> the duration of the query, and *if* holding such a pin were sufficient
> to guarantee the contents of the entry's partition data couldn't change
> or even move, then we could avoid doing so much copying. But as we
> discussed then, neither condition is true, and I don't think either one is
> cheap to make true. Certainly there's no logic in the relcache to detect
> changes of partition data like we do for, say, triggers.
I think we DO hold relations open for the duration of execution
(though not necessarily between planning and execution). And there is
code in RelationClearRelation to avoid changing rd_partkey and
rd_partdesc if no logical change has occurred.
The Enterprise PostgreSQL Company