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

From Tom Lane
Subject Re: Re: [COMMITTERS] pgsql: Rewrite GEQO's gimme_tree function so that it always finds a
Date
Msg-id 23769.1259793428@sss.pgh.pa.us
Whole thread Raw
In response to Re: Re: [COMMITTERS] pgsql: Rewrite GEQO's gimme_tree function so that it always finds a  ("Greg Sabino Mullane" <greg@turnstep.com>)
Responses Re: Re: [COMMITTERS] pgsql: Rewrite GEQO's gimme_tree function so that it always finds a  ("Greg Sabino Mullane" <greg@turnstep.com>)
List 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 by date:

Previous
From: "Greg Sabino Mullane"
Date:
Subject: Re: Re: [COMMITTERS] pgsql: Rewrite GEQO's gimme_tree function so that it always finds a
Next
From: Greg Stark
Date:
Subject: Re: SE-PgSQL patch review