Re: *_collapse_limit, geqo_threshold

On Tue, Jul 7, 2009 at 5:58 PM, Tom Lane<tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> 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

The whole point of these parameters is to save time planning large
complex queries -- which are rarely going to be the kind of short,
simple, fast to execute oltp queries where planning time makes a big
difference. The larger more complex the query the more likely it is to
be a long-running dss or olap style query where shaving one percent
off the runtime would be worth spending many seconds planning.

I propose that there's a maximum reasonable planning time which a
programmer woulod normally expect the database to be able to come up
with a plan for virtually any query within. Personally I would be
surprised if a plain EXPLAIN took more than, say, 30s. perhaps even
something more like 10s.

We should benchmark the planner on increasingly large sets of
relations on a typical developer machine and set geqo to whatever
value the planner can handle in that length of time. I suspect even at
10s you're talking about substantially larger values than the current
default.

--
greg
http://mit.edu/~gsstark/resume.pdf