Re: Check each of base restriction clauses for constant-FALSE-or-NULL

From: Richard Guo <guofenglinux(at)gmail(dot)com>
To: Ashutosh Bapat <ashutosh(dot)bapat(dot)oss(at)gmail(dot)com>
Cc: PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Check each of base restriction clauses for constant-FALSE-or-NULL
Date: 2023-10-10 08:32:55
Message-ID: CAMbWs48-L_Op2UP+bVxc6uA=KoFSOdBRG8srw5n=+FcCqmUCYA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, Oct 10, 2023 at 1:45 PM Ashutosh Bapat <ashutosh(dot)bapat(dot)oss(at)gmail(dot)com>
wrote:

> On Tue, Oct 10, 2023 at 11:09 AM Richard Guo <guofenglinux(at)gmail(dot)com>
> 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 size estimates for a base relation.
> > Neither of these two is a duplicate of the other. I think the theory
> > here is that it's always a win to mark a rel as dummy if possible as
> > early as we can.
>
> Right. Do you have an example where this could be demonstrated?

Hmm, do you think the two examples in the initial email of this thread
can serve the purpose, by observing how we avoid building access paths
for the dummy rel with this optimization?

Thanks
Richard

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message David Rowley 2023-10-10 08:48:51 Re: Use virtual tuple slot for Unique node
Previous Message Sergei Glukhov 2023-10-10 08:31:32 Re: Problem, partition pruning for prepared statement with IS NULL clause.