MIME-Version: 1.0
References: <CAO0i4_SSPV9TVxbbTRVLOnCyewopcc147fBZy=f2ABk15eHS+g@mail.gmail.com>
 <29821.1572706653@sss.pgh.pa.us> <CA+TgmobVH2zMh1ydAHdZzVYxbK-MNrs_R0hTOZbp=gu2abydaA@mail.gmail.com>
In-Reply-To: <CA+TgmobVH2zMh1ydAHdZzVYxbK-MNrs_R0hTOZbp=gu2abydaA@mail.gmail.com>
From: David Rowley <dgrowleyml@gmail.com>
Date: Sun, 5 May 2024 01:16:19 +1200
Message-ID: <CAApHDvoREwVZMzu6uNJDvq-p4G6kL69xkSZwjp4c4rdKpqQmmg@mail.gmail.com>
Subject: Re: On disable_cost
To: Robert Haas <robertmhaas@gmail.com>
Cc: Tom Lane <tgl@sss.pgh.pa.us>, 
	PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <https://www.postgresql.org/message-id/CAApHDvoREwVZMzu6uNJDvq-p4G6kL69xkSZwjp4c4rdKpqQmmg%40mail.gmail.com>
Precedence: bulk

On Sat, 4 May 2024 at 08:34, Robert Haas <robertmhaas@gmail.com> wrote:
> Another idea is to remove the ERROR mentioned above from
> set_cheapest() and just allow planning to continue even if some
> relations end up with no paths. (This would necessitate finding and
> fixing any code that could be confused by a pathless relation.) Then,
> if you get to the top of the plan tree and you have no paths there,
> redo the join search discarding the constraints (or maybe just some of
> the constraints, e.g. allow sequential scans and nested loops, or
> something).

I don't think you'd need to wait longer than where we do set_cheapest
and find no paths to find out that there's going to be a problem.

I don't think redoing planning is going to be easy or even useful. I
mean what do you change when you replan? You can't just do
enable_seqscan and enable_nestloop as if there's no index to provide
sorted input and the plan requires some sort, then you still can't
produce a plan.  Adding enable_sort to the list does not give me much
confidence we'll never fail to produce a plan either. It just seems
impossible to know which of the disabled ones caused the RelOptInfo to
have no paths.  Also, you might end up enabling one that caused the
planner to do something different than it would do today.  For
example, a Path that today incurs 2x disable_cost vs a Path that only
receives 1x disable_cost might do something different if you just went
and enabled a bunch of enable* GUCs before replanning.

> Now, I suppose it might be that even if we can't remove disable_cost,
> something along these lines is still worth doing, just to save CPU
> cycles. You could for example try planning with only non-disabled
> stuff and then do it over again with everything if that doesn't work
> out, still keeping disable_cost around so that you avoid disabled
> nodes where you can. But I'm kind of hoping that I'm missing something
> and there's some approach that could both kill disable_cost and save
> some cycles at the same time. If (any of) you have an idea, I'd love
> to hear it!

I think the int Path.disabledness idea is worth coding up to try it.
I imagine that a Path will incur the maximum of its subpath's
disabledness's then add_path() just needs to prefer lower-valued
disabledness Paths.

That doesn't get you the benefits of fewer CPU cycles, but where did
that come from as a motive to change this? There's no shortage of
other ways to make the planner faster if that's an issue.

David