On Thu, Oct 12, 2023 at 1:09 AM Tom Lane wrote:
> Pushed after a bit of fiddling with the comment.
Thanks for pushing!
Thanks
Richard
I wrote:
> So this logic in relation_excluded_by_constraints is just wrong ---
> premature optimization on my part, looks like.
Pushed after a bit of fiddling with the comment.
regards, tom lane
I wrote:
> Also, if you compare that test case to the one immediately following
> it, it's downright weird that we are presently smarter about
> optimizing the more complicated case. (I've not dug into exactly
> why that is; maybe worth running it to ground?)
The reason seems to be that joinrels.
Richard Guo writes:
> On Tue, Oct 10, 2023 at 5:10 PM David Rowley wrote:
>> After making the change, I saw the same regression test change as you
>> did, but didn't really feel like it was worth tackling separately from
>> the patch that we were working on.
> I was thinking that this change may
On Tue, Oct 10, 2023 at 5:10 PM David Rowley wrote:
> On Sat, 7 Oct 2023 at 22:44, Richard Guo wrote:
> >
> > In relation_excluded_by_constraints() when we're trying to figure out
> > whether the relation need not be scanned, one of the checks we do is to
> > detect constant-FALSE-or-NULL restri
On Sat, 7 Oct 2023 at 22:44, Richard Guo wrote:
>
> In relation_excluded_by_constraints() when we're trying to figure out
> whether the relation need not be scanned, one of the checks we do is to
> detect constant-FALSE-or-NULL restriction clauses. Currently we perform
> this check only when ther
On Tue, Oct 10, 2023 at 1:45 PM Ashutosh Bapat
wrote:
> On Tue, Oct 10, 2023 at 11:09 AM Richard Guo
> wrote:
> > Hm, I don't think so. get_gating_quals is called in createplan.c, where
> > we've selected the best path, while the optimization with my code
> > happens much earlier, when we set s
On Tue, Oct 10, 2023 at 11:09 AM Richard Guo wrote:
> Do you mean the const-folding? It happens in the preprocessing phase,
> specifically in eval_const_expressions().
Thanks.
> Hm, I don't think so. get_gating_quals is called in createplan.c, where
> we've selected the best path, while the op
On Mon, Oct 9, 2023 at 5:48 PM Ashutosh Bapat
wrote:
> postgres@312571=# explain (analyze, costs off) select * from pg_class
> t1 where oid = 1 and oid = 2;
> QUERY PLAN
> ---
> Result (actual
get pushed down to the baserel. All these cases would
> result in that the baserestrictinfo list might possibly have other
> members besides the FALSE constant.
>
> So I'm wondering if we should check each of base restriction clauses for
> constant-FALSE-or-NULL quals, like attached.
>
>
es the FALSE constant.
So I'm wondering if we should check each of base restriction clauses for
constant-FALSE-or-NULL quals, like attached.
Here are some examples.
-- #1 constant-FALSE generated by ECs
-- unpatched (in all branches)
explain (costs off) select * from t t1 where
11 matches
Mail list logo
