Re: Overriding the optimizer - Mailing list pgsql-performance

From Tom Lane
Subject Re: Overriding the optimizer
Date
Msg-id 18537.1134692629@sss.pgh.pa.us
Whole thread Raw
In response to Overriding the optimizer  ("Craig A. James" <cjames@modgraph-usa.com>)
Responses Re: Overriding the optimizer  ("Craig A. James" <cjames@modgraph-usa.com>)
Re: Overriding the optimizer  ("Craig A. James" <cjames@modgraph-usa.com>)
List pgsql-performance
"Craig A. James" <cjames@modgraph-usa.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

pgsql-performance by date:

Previous
From: Tom Lane
Date:
Subject: Re: How much expensive are row level statistics?
Next
From: Christopher Kings-Lynne
Date:
Subject: Re: Overriding the optimizer