From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | "Craig A(dot) James" <cjames(at)modgraph-usa(dot)com> |
Cc: | pgsql-performance(at)postgresql(dot)org |
Subject: | Re: Overriding the optimizer |
Date: | 2005-12-16 00:23:49 |
Message-ID: | 18537.1134692629@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
"Craig A. James" <cjames(at)modgraph-usa(dot)com> writes:
> I see this over and over. Tweak the parameters to "force" a certain
> plan, because there's no formal way for a developer to say, "I know
> the best plan."
I think you've misunderstood those conversations entirely. The point
is not to force the planner into a certain plan, it is to explore what's
going on with a view to understanding why the planner isn't making a
good choice, and thence hopefully improve the planner in future. (Now,
that's not necessarily what the user with an immediate problem is
thinking, but that's definitely what the developers are thinking.)
> There isn't a database in the world that is as smart as a developer,
People who are convinced they are smarter than the machine are often
wrong ;-). If we did put in the nontrivial amount of work needed to
have such a facility, it would probably get abused more often than it
was used correctly. I'd rather spend the work on making the planner
better.
This discussion has been had before (many times) ... see the -hackers
archives for detailed arguments. The one that carries the most weight
in my mind is that planner hints embedded in applications will not adapt
to changing circumstances --- the plan that was best when you designed
the code might not be best today.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Christopher Kings-Lynne | 2005-12-16 01:50:44 | Re: Overriding the optimizer |
Previous Message | Tom Lane | 2005-12-16 00:06:39 | Re: How much expensive are row level statistics? |