Re: BUG #17885: slow planning constraint_exclusion
От | David Rowley |
---|---|
Тема | Re: BUG #17885: slow planning constraint_exclusion |
Дата | |
Msg-id | CAApHDvr4EKaccRcf8+2XBfayO=Q5qrJK_XeFFt3=Xi+GoNvKUg@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: BUG #17885: slow planning constraint_exclusion (Maxim Boguk <maxim.boguk@gmail.com>) |
Список | pgsql-bugs |
On Wed, 5 Apr 2023 at 12:30, Maxim Boguk <maxim.boguk@gmail.com> wrote: > As the person responsible for keeping the system where this problem was observed in production working I cannot just turnoff enable_partition_pruning on a 6TB archive database with multiple huge partitioned tables (it will have a very negativeeffect on the whole system performance). I guess I didn't spell out what I was suggesting because you'd already suggested it yourself, so I thought it was clear... I should have been more explicit. What I was suggesting is that if you don't like the fact that relation_excluded_by_constraints() is running for each partition in this query, then switch it off. As you've already mentioned, the constraint_exclusion GUC is how that's done. The setting you'll want to consider is "off". You'll need to do the analysis into if there are any places in the application that are benefiting from your current setting of constraint_exclusion, if there are none, then you might want to consider just changing the setting in postgresql.conf. This not at all the same as turning off enable_partition_pruning. David
В списке pgsql-bugs по дате отправления: