Re: upper planner path-ification

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: upper planner path-ification
Дата
Msg-id 30117.1431876866@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: upper planner path-ification  (Andrew Gierth <andrew@tao11.riddles.org.uk>)
Ответы Re: upper planner path-ification  (Andrew Gierth <andrew@tao11.riddles.org.uk>)
Список pgsql-hackers
Andrew Gierth <andrew@tao11.riddles.org.uk> writes:
> "Robert" == Robert Haas <robertmhaas@gmail.com> writes:
>  Robert> I think grouping_planner() is badly in need of some refactoring
>  Robert> just to make it shorter.  It's over 1000 lines of code, which
>  Robert> IMHO is a fairly ridiculous length for a single function.

> If there's interest, we could do that specific task as part of adding
> hashagg support for grouping sets (which would otherwise make it even
> longer), or as preparatory work for that.

I think that refactoring without changing anything about the way it works
will be painful and probably ultimately a dead end.  As an example, the
current_pathkeys local variable is state that's needed throughout that
process, so you'd need some messy notation to pass it around (unless you
stuck it into PlannerRoot, which would be ugly too).  But that would
go away in a path-ified universe, because each Path would be marked as
to its output sort order.  More, a lot of the code that you'd be
relocating is code that we should be trying to get rid of altogether,
not just relocate (to wit all the stuff that does cost-based comparisons
of alternatives).

So I'm all for refactoring, but I think it will happen as a natural
byproduct of path-ification, and otherwise would be rather forced.
        regards, tom lane



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Andrew Gierth
Дата:
Сообщение: Re: upper planner path-ification
Следующее
От: Dmitry Dolgov
Дата:
Сообщение: Re: jsonb concatenate operator's semantics seem questionable