Re: Should we add GUCs to allow partition pruning to be disabled?

Поиск
Список
Период
Сортировка
От David G. Johnston
Тема Re: Should we add GUCs to allow partition pruning to be disabled?
Дата
Msg-id CAKFQuwbTz7M4D0M1C-XpzSO-8izjAzq80H=87Z_yXSom7yWDqA@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Should we add GUCs to allow partition pruning to be disabled?  (Justin Pryzby <pryzby@telsasoft.com>)
Ответы Re: Should we add GUCs to allow partition pruning to be disabled?  (David Rowley <david.rowley@2ndquadrant.com>)
Список pgsql-hackers
On Tue, Apr 17, 2018 at 5:42 PM, Justin Pryzby <pryzby@telsasoft.com> wrote:
On Wed, Apr 18, 2018 at 12:07:18PM +1200, David Rowley wrote:
> In PG10 the planner's partition pruning could be disabled by changing
> the constraint_exclusion GUC to off.  This is still the case for PG11,
> but only for UPDATE and DELETE queries. There is currently no way to
> disable partition pruning for SELECT.
>
> Should we allow this?

> 3. No new GUCs / Do nothing.

Maybe this is divergent from the details of the implementation; but, from a
user's perspective: why not continue to use constraint_exclusion?

I would suggest to add zero new GUCs:

0. constraint_exclusion={off,partition,on,PLANNER*,EXECUTOR*}

​My initial reaction is that we need to fix the bug introduced in v10 - leaving constraint_exclusion working as it has historically and not affect the new-as-of-10 ability to prune (maybe better termed as skip...) partitions known during execution to contain no qualified tuples.

David J.

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

Предыдущее
От: Michael Paquier
Дата:
Сообщение: Re: reloption to prevent VACUUM from truncating empty pages at theend of relation
Следующее
От: David Rowley
Дата:
Сообщение: Re: Should we add GUCs to allow partition pruning to be disabled?