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

Re: generalizing the planner knobs

From: Greg Stark <gsstark(at)mit(dot)edu>
To: Rod Taylor <pg(at)rbt(dot)ca>
Cc: Greg Stark <gsstark(at)mit(dot)edu>, "Pollard, Mike" <mpollard(at)cincom(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, "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 20:49:02
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
Rod Taylor <pg(at)rbt(dot)ca> writes:

> > 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'
> Why not?
> The missing capability in this case is to be able to provide or generate
> (self learning?) statistics for a function that describe a typical result
> and the cost of getting that result.

Ok, try "WHERE radius_authenticate(user, (select ...), ?)"

The point is that you can improve the estimates the planner gets. But you can
never make them omniscient. There will always be cases where the user knows
his data more than the planner. And those hints are still valid when a new
optimizer has new plans available.

This is different from hints that tell the planner what plan to use. Every
situation where the predicted cost is inaccurate despite accurate estimates
represents a fixable bug in the optimizer's cost model. When a new version of
the optimizer is available with a more accurate cost model or new available
plans those kinds of hints will only get in the way.


In response to


pgsql-hackers by date

Next:From: Rod TaylorDate: 2005-12-02 20:51:52
Subject: Re: generalizing the planner knobs
Previous:From: Bruce MomjianDate: 2005-12-02 20:44:11
Subject: Re: Numeric 508 datatype

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