Re: Wired if-statement in gen_partprune_steps_internal

Поиск
Список
Период
Сортировка
От David Rowley
Тема Re: Wired if-statement in gen_partprune_steps_internal
Дата
Msg-id CAApHDvr7xQP7YSZua7o9gyjJiHXzbd7y=SOYM4gr_ACtLm1=Tw@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Wired if-statement in gen_partprune_steps_internal  (Amit Langote <amitlangote09@gmail.com>)
Ответы Re: Wired if-statement in gen_partprune_steps_internal
Re: Wired if-statement in gen_partprune_steps_internal
Список pgsql-hackers
On Wed, 7 Apr 2021 at 21:04, Amit Langote <amitlangote09@gmail.com> wrote:
>
> On Wed, Apr 7, 2021 at 4:43 PM David Rowley <dgrowleyml@gmail.com> wrote:
> > However, it does change the meaning of what PARTCLAUSE_MATCH_STEPS
> > does. If we ever needed to expand what PARTCLAUSE_MATCH_STEPS does,
> > then we'll have less flexibility with the newly updated code. For
> > example if we needed to return multiple steps and only combine them at
> > the top level then we now can't.  I feel there's a good possibility
> > that we'll never need to do that, but I'm not certain of that.
> >
> > I'm keen to hear your opinion on this.
>
> That's a good point.  So maybe gen_partprune_steps_internal() should
> continue to return a list of steps, the last of which would be an
> intersect step to combine the results of the earlier multiple steps.
> We should still fix the originally reported issue that
> gen_prune_steps_from_opexps() seems to needlessly add an intersect
> step.

I was hoping you'd just say that we'll likely not need to do that and
if we ever did we could adapt the code at that time. :)

Thinking more about it, these steps we're talking about are generated
from a recursive call to gen_partprune_steps_internal(). I'm finding
it very hard to imagine that we'd want to combine steps generated in
some recursive call with steps from outside that same call.  Right now
we recuse into AND BoolExprs OR BoolExprs. I'm struggling to think of
why we'd want to combine a set of steps we generated processing some
of those with steps from outside that BoolExpr. If we did, we might
want to consider teaching canonicalize_qual() to fix it beforehand.

e.g.

postgres=# explain select * from ab where (a = 1 and b = 1) or (a = 1
and b = 2);
                    QUERY PLAN
---------------------------------------------------
 Seq Scan on ab  (cost=0.00..49.55 rows=1 width=8)
   Filter: ((a = 1) AND ((b = 1) OR (b = 2)))
(2 rows)

If canonicalize_qual() had been unable to rewrite that WHERE clause
then I could see that we might want to combine steps from other
recursive quals. I'm thinking right now that I'm glad
canonicalize_qual() does that hard work for us.  (I think partprune.c
could handle the original WHERE clause as-is in this example
anyway...)

David



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

Предыдущее
От: Yugo NAGATA
Дата:
Сообщение: Re: Implementing Incremental View Maintenance
Следующее
От: Amit Kapila
Дата:
Сообщение: Set access strategy for parallel vacuum workers