Re: [HACKERS] path toward faster partition pruning

Поиск
Список
Период
Сортировка
От Amit Langote
Тема Re: [HACKERS] path toward faster partition pruning
Дата
Msg-id d172e2cf-3990-f25a-5067-b52c85c68d6e@lab.ntt.co.jp
обсуждение исходный текст
Ответ на Re: [HACKERS] path toward faster partition pruning  (David Rowley <david.rowley@2ndquadrant.com>)
Ответы Re: [HACKERS] path toward faster partition pruning
Список pgsql-hackers
Hi David.

On 2018/03/25 14:32, David Rowley wrote:
> On 25 March 2018 at 18:28, David Rowley <david.rowley@2ndquadrant.com> wrote:
>> The attached delta applies on top of v39 plus delta1.
> 
> Sorry, the attached should do this. Ignore the last attachment.

I have incorporated both of your delta1 and delta2_1 patches.

Your proposed change to determine the cross-type comparison function OID
during planning itself is a good one, although I wasn't sure why it was
done only for the <> operators.  I also implemented that for
PartitionPruneStepOp steps.

Also, I started thinking that implementing pruning using <> operators with
a PartitionPruneCombineOp was not such a great idea.  That needed us to
add argexprs and argcmpfns to that struct, which seemed a bit odd.  I
defined a new pruning node type called PartitionPruneStepOpNe, which still
seems a bit odd, but given that our support for pruning using <> is quite
specialized, that may be fine.

I added a bunch of hopefully informative comments in partprune.c and for
the struct definitions of pruning step nodes.

Please find attached find a new version.

Thanks,
Amit

Вложения

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Thomas Munro
Дата:
Сообщение: Re: new function for tsquery creartion
Следующее
От: Masahiko Sawada
Дата:
Сообщение: Re: PATCH: Exclude unlogged tables from base backups