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
|
Список | 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 по дате отправления: