Re: Wired if-statement in gen_partprune_steps_internal - Mailing list pgsql-hackers

From David Rowley
Subject Re: Wired if-statement in gen_partprune_steps_internal
Date
Msg-id CAApHDvr7xQP7YSZua7o9gyjJiHXzbd7y=SOYM4gr_ACtLm1=Tw@mail.gmail.com
Whole thread Raw
In response to Re: Wired if-statement in gen_partprune_steps_internal  (Amit Langote <amitlangote09@gmail.com>)
Responses Re: Wired if-statement in gen_partprune_steps_internal  (David Rowley <dgrowleyml@gmail.com>)
Re: Wired if-statement in gen_partprune_steps_internal  (Amit Langote <amitlangote09@gmail.com>)
List 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 by date:

Previous
From: Yugo NAGATA
Date:
Subject: Re: Implementing Incremental View Maintenance
Next
From: Amit Kapila
Date:
Subject: Set access strategy for parallel vacuum workers