Re: generalizing the planner knobs

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

In response to

Responses

Browse pgsql-hackers by date

  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