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.
