Re: Enhanced containment selectivity function
От | Matteo Beccati |
---|---|
Тема | Re: Enhanced containment selectivity function |
Дата | |
Msg-id | 42F24BCA.2030802@beccati.com обсуждение исходный текст |
Ответ на | Re: Enhanced containment selectivity function (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Enhanced containment selectivity function
|
Список | pgsql-hackers |
Tom Lane wrote: > After looking at this a little, it doesn't seem like it has much to do > with the ordinary 2-D notion of containment. In most of the core > geometric types, the "histogram" ordering is based on area, and so > testing the histogram samples against the query doesn't seem like it's > able to give very meaningful containment results --- the items shown > in the histogram could have any locations whatever. > > The approach might be sensible for ltree's isparent operator --- I don't > have a very good feeling for the behavior of that operator, but it looks > like it has at least some relationship to the ordering induced by the > ltree < operator. Actually, this was one of my doubts. The custom function seem to work well with ltree, but this also could be dependant from the way my dataset is organized. > So my thought is that (assuming Oleg and Teodor agree this is sensible > for ltree) we should put the selectivity function into contrib/ltree, > not directly into the core. It might be best to call it something like > "parentsel", too, to avoid giving the impression that it has something > to do with 2-D containment. > > Also, you should think about using the most-common-values list as well > as the histogram. I would guess that many ltree applications would have > enough duplicate entries that the MCV list represents a significant > fraction of the total population. Keep in mind when thinking about this > that the histogram describes the population of data *exclusive of the > MCV entries*. I also agree that "parentsel" would better fit its purpose. My patch was originally using MCV without good results, until I realized that MCV was empty because the column contains unique values :) I'll look into adding a MCV check to it. Moving it in contrib/ltree would be more difficult to me because it depends on other functions declared in selfuncs.c (get_restriction_variable, etc). Thank you for your feedback Best regards -- Matteo Beccati http://phpadsnew.com/ http://phppgads.com/
В списке pgsql-hackers по дате отправления: