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 >> 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
