Re: Planner producing 100% duplicate subplans when unneeded - Mailing list pgsql-bugs

From Daniel Grace
Subject Re: Planner producing 100% duplicate subplans when unneeded
Date
Msg-id AANLkTinyfs60cVNh6X8rT+63oQ2Q93njG28uCbZTbh+A@mail.gmail.com
Whole thread Raw
In response to Re: Planner producing 100% duplicate subplans when unneeded  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: Planner producing 100% duplicate subplans when unneeded  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-bugs
As a theoretical question (I'm not savvy on Postgres's code but might
be intrigued enough to beat on it anyways), is it feasible to do an
additional pass on the query plan that essentially goes:

- Are these two subplans identical?
- Are they at the same part of the tree?

and if both of these conditions are true, discard one subplan and
rewrite all references to point to the other one?

Assuming it IS possible, are there any particular situations where it
wouldn't work?

On Mon, Oct 4, 2010 at 11:47 AM, Robert Haas <robertmhaas@gmail.com> wrote:
> On Mon, Sep 27, 2010 at 5:09 PM, Daniel Grace <dgrace@wingsnw.com> wrote:
>> Is there any chance this might be looked at in a future release?
>
> This is another interesting example of a case where an inlining-type
> optimization (which is effectively what's happening here, I think)
> turns out to be a negative. =A0We had one a while back that involved
> actual function inlining, which is not quite what's happening here,
> but it's close. =A0It doesn't seem too hard to figure out whether or not
> inlining is a win (non-trivial subexpressions should probably never
> get duplicated), but nobody's gotten around to writing the logic to
> make it work yet. =A0One useful technique is to stick "OFFSET 0" into
> the subquery; that prevents it from being inlined and gives you
> something more like the plan you were hoping for.
>
> Whether or not this will get looked at in a future release is a tough
> question to answer. =A0It's possible that someone (most likely, Tom)
> will get motivated to fix this out of sheer annoyance with the current
> behavior, or will notice a way to improve it incidentally while making
> some other change. =A0But of course the only way to make sure it gets
> fixed is to do it yourself (or pay someone to do it).
>
> --
> Robert Haas
> EnterpriseDB: http://www.enterprisedb.com
> The Enterprise Postgres Company
>



--=20
Daniel Grace
AGE, LLC
System Administrator and Software Developer
dgrace@wingsnw.com // (425)327-0079 // www.wingsnw.com

pgsql-bugs by date:

Previous
From: Alex Hunsaker
Date:
Subject: Re: BUG #5692: fatal error
Next
From: Robert Haas
Date:
Subject: Re: Planner producing 100% duplicate subplans when unneeded