Re: Planner producing 100% duplicate subplans when unneeded

Поиск
Список
Период
Сортировка
От Daniel Grace
Тема Re: Planner producing 100% duplicate subplans when unneeded
Дата
Msg-id AANLkTinyfs60cVNh6X8rT+63oQ2Q93njG28uCbZTbh+A@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Planner producing 100% duplicate subplans when unneeded  (Robert Haas <robertmhaas@gmail.com>)
Ответы Re: Planner producing 100% duplicate subplans when unneeded
Список 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 по дате отправления:

Предыдущее
От: Alex Hunsaker
Дата:
Сообщение: Re: BUG #5692: fatal error
Следующее
От: Robert Haas
Дата:
Сообщение: Re: Planner producing 100% duplicate subplans when unneeded