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

From David Rowley
Subject Re: why partition pruning doesn't work?
Date
Msg-id CAKJS1f_BFePMt1xn6Zijum2dCLmM3dadN9dm=fCcnfK-aPp-dQ@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?
List pgsql-hackers
On 13 June 2018 at 16:15, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> It seems not to be that bad: we just need a shutdown call for the
> PartitionPruneState, and then we can remember the open relation there.
> The attached is based on David's patch from yesterday.
>
> I'm still a bit annoyed at the fmgr_info_copy calls in this.  It'd be
> better to use the FmgrInfos in the relcache when applicable.  However,
> mixing those with the cross-type ones would seem to require that we change
> the API for get_matching_hash_bounds et al from taking "FmgrInfo *" to
> taking "FmgrInfo **", which looks rather invasive.

I've looked over this and it seems better than mine. Especially so
that you've done things so that the FmgrInfo is copied into a memory
context that's not about to get reset.

One small thing is that I'd move the:

context.partrel = NULL;

to under:

/* These are not valid when being called from the planner */

-- 
 David Rowley                   http://www.2ndQuadrant.com/
 PostgreSQL Development, 24x7 Support, Training & Services


pgsql-hackers by date:

Previous
From: Andrew Gierth
Date:
Subject: Re: BUG #15237: I got "ERROR: source for a multiple-column UPDATE item must be a sub-SELECT or ROW() expression"
Next
From: Michael Paquier
Date:
Subject: Re: Portability concerns over pq_sendbyte?