Re: BUG #17885: slow planning constraint_exclusion

From: David Rowley <dgrowleyml(at)gmail(dot)com>
To: Maxim Boguk <maxim(dot)boguk(at)gmail(dot)com>
Cc: sk(at)zsrv(dot)org, pgsql-bugs(at)lists(dot)postgresql(dot)org
Subject: Re: BUG #17885: slow planning constraint_exclusion
Date: 2023-04-05 00:45:06
Message-ID: CAApHDvr4EKaccRcf8+2XBfayO=Q5qrJK_XeFFt3=Xi+GoNvKUg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

On Wed, 5 Apr 2023 at 12:30, Maxim Boguk <maxim(dot)boguk(at)gmail(dot)com> wrote:
> As the person responsible for keeping the system where this problem was observed in production working I cannot just turn off enable_partition_pruning on a 6TB archive database with multiple huge partitioned tables (it will have a very negative effect 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

In response to

Browse pgsql-bugs by date

  From Date Subject
Next Message Alvaro Herrera 2023-04-05 07:33:56 Re: BUG #17886: Error disabling user triggers on a partitioned table
Previous Message Maxim Boguk 2023-04-05 00:30:17 Re: BUG #17885: slow planning constraint_exclusion