On Thu, Oct 12, 2006 at 02:25:29PM +0100, Simon Riggs wrote:
> The CREATE OPERATOR command already has a RESTRICT=res_proc clause which
> provides the ability to attach selectivity functions onto an operator.
> So this is already possible if you turn radius_authenticate() into an
> operator. The function parameters are passed to the selectivity
> function, so you can use that to steer the selectivity.
> Perhaps this should be allowed on the CREATE FUNCTION command when a
> procedure returns boolean.

Why limit it to booleans? For many functions you can get a reasonable
estimate of the resulting data by feeding the keys of the histogram
through the function.

If you know how the data in "field" is distributed, you can take a good
guess at the distribution of upper(field).

> Greg is right though, there are some times when the default selectivity
> won't match what we know to be the case. His example of a function which
> might normally be expected to return 99.9% true being used to evaluate a
> list of suspected attempts where the return might well be 20% true is a
> good one.

In the extreme case you could drop the histogram in a transaction, but
I can see use-case for declaring a histogram for the current session
only, or even having profile to select from. I don't think annotating
the query itself is a particularly good idea.

The hard part is stoing the histograms and getting the planner to use
them, once that happens the really is trivial.

Have a nice day,
Martijn van Oosterhout   <kleptog@svana.org>   http://svana.org/kleptog/
> From each according to his ability. To each according to his ability to 
> litigate.

Attachment: signature.asc
Description: Digital signature

Reply via email to