Skip site navigation (1) Skip section navigation (2)

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 (view raw or flat)
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

pgsql-hackers by date

Next:From: Tom LaneDate: 2005-12-02 07:11:26
Subject: Re: Fork-based version of pgbench
Previous:From: Trent ShipleyDate: 2005-12-02 07:06:28
Subject: Re: generalizing the planner knobs

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group