Re: Problem with default partition pruning
От | Alvaro Herrera |
---|---|
Тема | Re: Problem with default partition pruning |
Дата | |
Msg-id | 20190806171740.GA7610@alvherre.pgsql обсуждение исходный текст |
Ответ на | Re: Problem with default partition pruning (Amit Langote <amitlangote09@gmail.com>) |
Ответы |
Re: Problem with default partition pruning
|
Список | pgsql-hackers |
Hello, On 2019-Aug-06, Amit Langote wrote: > On Mon, Aug 5, 2019 at 11:39 PM Alvaro Herrera <alvherre@2ndquadrant.com> wrote: > > I don't think that we care about what happens with constraint_exclusion > > is on. That's not the recommended value for that setting anyway. > > One issue I expressed with unconditionally applying constraint > exclusion in partprune.c the way the third patch proposes to do it is > that it means we end up performing the same processing twice for a > given relation in come cases. Specifically, when constraint_exclusion > is set to on, relation_excluded_by_constraints() that occurs when > set_rel_sizes() is applied to that relation would perform the same > proof. But maybe we shouldn't worry about the repetition too much, > because it's not likely to be very problematic in practice, > considering that setting constraint_exclusion to on is not > recommended. Well, if this is really all that duplicative, one thing we could do is run this check in get_partprune_steps_internal only if constraint_exclusion is a value other than on; we should achieve the same effect with no repetition. Patch for that is attached. However, if I run the server with constraint_exclusion=on, the regression test fail with the attached diff. I didn't look at what test is failing, but it seems to me that it's not really duplicative in all cases, only some. Therefore we can't do it. -- Álvaro Herrera https://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
Вложения
В списке pgsql-hackers по дате отправления: