On Tue, Jul 7, 2009 at 5:58 PM, Tom Lane<t...@sss.pgh.pa.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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers