Re: why partition pruning doesn't work?

Поиск
Список
Период
Сортировка
От David Rowley
Тема Re: why partition pruning doesn't work?
Дата
Msg-id CAKJS1f_BFePMt1xn6Zijum2dCLmM3dadN9dm=fCcnfK-aPp-dQ@mail.gmail.com
обсуждение исходный текст
Ответ на Re: why partition pruning doesn't work?  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: why partition pruning doesn't work?  (Tom Lane <tgl@sss.pgh.pa.us>)
Список 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 по дате отправления:

Предыдущее
От: Andrew Gierth
Дата:
Сообщение: Re: BUG #15237: I got "ERROR: source for a multiple-column UPDATE item must be a sub-SELECT or ROW() expression"
Следующее
От: Michael Paquier
Дата:
Сообщение: Re: Portability concerns over pq_sendbyte?