From: | Greg Stark <gsstark(at)mit(dot)edu> |
---|---|
To: | "Pollard, Mike" <mpollard(at)cincom(dot)com> |
Cc: | "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>, "Greg Stark" <gsstark(at)mit(dot)edu>, "Jonah H(dot) Harris" <jonah(dot)harris(at)gmail(dot)com>, "Neil Conway" <neilc(at)samurai(dot)com>, "pgsql-hackers" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: generalizing the planner knobs |
Date: | 2005-12-02 07:09:49 |
Message-ID: | 87d5kgf002.fsf@stark.xeocode.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
"Pollard, Mike" <mpollard(at)cincom(dot)com> writes:
> Optimizer hints were added because some databases just don't have a very
> smart optimizer. But you are much better served tracking down cases in
> which the optimizer makes a bad choice, and teaching the optimizer how
> to make a better one.
You more or less missed my entire point.
You can always teach the optimizer to make better decisions based on good
data. Your statement is basically right when talking about tweaking the
optimizer's decisions to ignore its best judgement.
But there are many many cases where the data the optimizer has available isn't
good and for good reason. And in plenty of those cases the data the optimizer
has available *can't* be good.
In the extreme, no amount of added intelligence in the optimizer is going to
help it come up with any sane selectivity estimate for something like
WHERE radius_authenticate(user) = 'OK'
--
greg
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2005-12-02 07:11:26 | Re: Fork-based version of pgbench |
Previous Message | Trent Shipley | 2005-12-02 07:06:28 | Re: generalizing the planner knobs |