Re: why partition pruning doesn't work?

On Tue, Jun 12, 2018 at 12:25 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Robert Haas <robertmhaas(at)gmail(dot)com> writes:
>> On Mon, Jun 11, 2018 at 6:24 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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
>> https://www.postgresql.org/message-id/flat/CA%2BTgmoYKToP4-adCFFRNrO21OGuH%3Dphx-fiB1dYoqksNYX6YHQ%40mail.gmail.com
>> 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.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company