Re: a path towards replacing GEQO with something better - Mailing list pgsql-hackers

From Tom Lane
Subject Re: a path towards replacing GEQO with something better
Date
Msg-id 427089.1623776428@sss.pgh.pa.us
Whole thread Raw
In response to Re: a path towards replacing GEQO with something better  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: a path towards replacing GEQO with something better
List pgsql-hackers
Robert Haas <robertmhaas@gmail.com> writes:
> One idea I just ran across in
> https://15721.courses.cs.cmu.edu/spring2020/papers/22-costmodels/p204-leis.pdf
> is to try to economize by skipping consideration of bushy plans. We
> could start doing that when some budget is exceeded, similar to what
> you are proposing here, but probably the budget for skipping
> consideration of bushy plans would be smaller than the budget for
> switching to IDP. The idea of skipping bushy plan generation in some
> cases makes sense to me intuitively because most of the plans
> PostgreSQL generates are mostly left-deep, and even when we do
> generate bushy plans, they're not always a whole lot better than the
> nearest equivalent left-deep plan. The paper argues that considering
> bushy plans makes measurable gains, but also that failure to consider
> such plans isn't catastrophically bad.

It's not catastrophically bad until you hit a query where the only
correct plans are bushy.  These do exist, and I think they're not
that uncommon.

Still, I take your point that maybe we could ratchet down the cost of
exhaustive search by skimping on this part.  Maybe it'd work to skip
bushy so long as we'd found at least one left-deep or right-deep path
for the current rel.

            regards, tom lane



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: snapshot too old issues, first around wraparound and then more.
Next
From: Tom Lane
Date:
Subject: Re: change logging defaults