Re: Should we add GUCs to allow partition pruning to be disabled?
От | Alvaro Herrera |
---|---|
Тема | Re: Should we add GUCs to allow partition pruning to be disabled? |
Дата | |
Msg-id | 20180420181955.53gkhhcif36nhgxo@alvherre.pgsql обсуждение исходный текст |
Ответ на | Re: Should we add GUCs to allow partition pruning to be disabled? (Amit Langote <Langote_Amit_f8@lab.ntt.co.jp>) |
Список | pgsql-hackers |
Amit Langote wrote: > Sorry, I should have said what I said after quoting only the last sentence > of what you had said. That is, I want to the new GUC to be the only > determiner of whether the pruning occurs or not for partitioned tables. > To implement that behavior, it will have to override the setting of > constraint_exclusion (the parameter) in *some* cases, because some > commands still rely on constraint exclusion (the algorithm) as the > underlying pruning mechanism. I agree -- it will make more sense now, and will continue to make sense later when we remove usage of constraint exclusion for upd/del, to make it work as you suggest: * if the table is partitioned, do constraint exclusion based on enable_partition_prune=on rather than constraint_exclusion=partition. This will only affect upd/del, because the select queries would be affected by the enable_partition_prune anyway since constraint_exclusion does not apply. * If the table is using regular inheritance, continue to use the original behavior. > Now, the "override the setting of constraint_exclusion" implementation > may not be the most popular choice in the end. I guess there are different ways to implement it. Supposedly this is going to disappear in pg12, so I don't think it's a big deal. -- Álvaro Herrera https://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
В списке pgsql-hackers по дате отправления: