Re: Hints WAS: Index Tuning Features
От | Martijn van Oosterhout |
---|---|
Тема | Re: Hints WAS: Index Tuning Features |
Дата | |
Msg-id | 20061012140855.GI11723@svana.org обсуждение исходный текст |
Ответ на | Re: Hints WAS: Index Tuning Features (Simon Riggs <simon@2ndquadrant.com>) |
Список | pgsql-hackers |
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.
В списке pgsql-hackers по дате отправления: