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 <[email protected]> http://svana.org/kleptog/ > From each according to his ability. To each according to his ability to > litigate.
signature.asc
Description: Digital signature
