Re: *_collapse_limit, geqo_threshold

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: *_collapse_limit, geqo_threshold
Дата
Msg-id 9101.1246985939@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: *_collapse_limit, geqo_threshold  ("Kevin Grittner" <Kevin.Grittner@wicourts.gov>)
Ответы Re: *_collapse_limit, geqo_threshold  (Greg Stark <gsstark@mit.edu>)
Re: *_collapse_limit, geqo_threshold  (Jan Urbański <wulczer@wulczer.org>)
Список pgsql-hackers
"Kevin Grittner" <Kevin.Grittner@wicourts.gov> writes:
> I guess the question is whether there is anyone who has had a contrary
> experience.  (There must have been some benchmarks to justify adding
> geqo at some point?)

The CVS history shows that geqo was integrated on 1997-02-19, which
I think means that it must have been developed against Postgres95
(or even earlier Berkeley releases?).  That was certainly before any
of the current community's work on the optimizer began.  A quick look
at the code as it stood on that date suggests that the regular
optimizer's behavior for large numbers of rels was a lot worse than it
is today --- notably, it looks like it would consider a whole lot more
Cartesian-product joins than we do now; especially if you had "bushy"
mode turned on, which you'd probably have to do to find good plans in
complicated cases.  There were also a bunch of enormous inefficiencies
that we've whittled down over time, such as the mechanisms for comparing
pathkeys or the use of integer Lists to represent relid sets.

So while I don't doubt that geqo was absolutely essential when it was
written, it's fair to question whether it still provides a real win.
And we could definitely stand to take another look at the default
thresholds.
        regards, tom lane


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

Предыдущее
От: "David E. Wheeler"
Дата:
Сообщение: Re: Maintenance Policy?
Следующее
От: Greg Stark
Дата:
Сообщение: Re: GRANT ON ALL IN schema