Re: Re: [COMMITTERS] pgsql: Rewrite GEQO's gimme_tree function so that it always finds a

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Re: [COMMITTERS] pgsql: Rewrite GEQO's gimme_tree function so that it always finds a
Дата
Msg-id 23769.1259793428@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: Re: [COMMITTERS] pgsql: Rewrite GEQO's gimme_tree function so that it always finds a  ("Greg Sabino Mullane" <greg@turnstep.com>)
Ответы Re: Re: [COMMITTERS] pgsql: Rewrite GEQO's gimme_tree function so that it always finds a  ("Greg Sabino Mullane" <greg@turnstep.com>)
Список pgsql-hackers
"Greg Sabino Mullane" <greg@turnstep.com> writes:
>> The reason this is a configurable parameter is so that
>> people can tune it to their own needs.  I think the current
>> default fits all right with our usual policy of being
>> conservative about hardware requirements.

> That only makes sense if you adjust it accordingly over time.
> It's been 12 for a long time - since January 2004 - while
> hardware has radically improved in that time, which means that
> either 12 was too high five years ago, is too low now, or is very
> insensitive to the speed of the hardware. I submit it's probably
> more of the second option.

I don't have a problem with the third explanation ;-).  The issue here
is really planner speed relative to execution speed, and that's not so
hardware-sensitive as all that.  Yeah, you can plan a 12-join query
way faster than ten years ago, but you can execute it way faster too,
and that's what drives expectations for planning speed.  Flat-planning
a 15-way query costs just as much more relative to a 12-way query as
it did ten years ago.
        regards, tom lane


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

Предыдущее
От: "Greg Sabino Mullane"
Дата:
Сообщение: Re: Re: [COMMITTERS] pgsql: Rewrite GEQO's gimme_tree function so that it always finds a
Следующее
От: Greg Stark
Дата:
Сообщение: Re: SE-PgSQL patch review