Re: why partition pruning doesn't work? - Mailing list pgsql-hackers

From Robert Haas
Subject Re: why partition pruning doesn't work?
Date
Msg-id CA+TgmoZi9hwHb4nZxCeh1TTT8rGq6AYN1Q8o5uXhiPZ3sr6o9g@mail.gmail.com
Whole thread Raw
In response to Re: why partition pruning doesn't work?  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: why partition pruning doesn't work?
Re: why partition pruning doesn't work?
List pgsql-hackers
On Tue, Jun 12, 2018 at 12:25 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Robert Haas <robertmhaas@gmail.com> writes:
>> On Mon, Jun 11, 2018 at 6:24 PM, Tom Lane <tgl@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


pgsql-hackers by date:

Previous
From: Nico Williams
Date:
Subject: Re: [PATCH v18] GSSAPI encryption support
Next
From: Andrew Gierth
Date:
Subject: Re: assert in nested SQL procedure call in current HEAD