Re: Selectivity estimation for inet operators
От | Heikki Linnakangas |
---|---|
Тема | Re: Selectivity estimation for inet operators |
Дата | |
Msg-id | 53FF26C1.2070000@vmware.com обсуждение исходный текст |
Ответ на | Re: Selectivity estimation for inet operators (Emre Hasegeli <emre@hasegeli.com>) |
Ответы |
Re: Selectivity estimation for inet operators
Re: Selectivity estimation for inet operators |
Список | pgsql-hackers |
On 08/26/2014 12:44 PM, Emre Hasegeli wrote: >> I agree with you that we can support other join type and anti join later, >> If others don’t have any objection in doing other parts later I will mark as "Ready For Committer". > > I updated the patch to cover semi and anti joins with eqjoinsel_semi(). > I think it is better than returning a constant. The new version > attached with the new version of the test script. Can you please > look at it again and mark it as "ready for committer" if it seems okay > to you? I took a quick look at this. Some questions: * Isn't "X >> Y" equivalent to "network_scan_first(X) < Y AND network_scan_last(X) > Y"? Or at least close enough for selectivity estimation purposes? Pardon my ignorance - I'm not too familiar with the inet datatype - but how about just calling scalarineqsel for both bounds? * inet_mcv_join_selec() is O(n^2) where n is the number of entries in the MCV lists. With the max statistics target of 10000, a worst case query on my laptop took about 15 seconds to plan. Maybe that's acceptable, but you went through some trouble to make planning of MCV vs histogram faster, by the log2 method to compare only some values, so I wonder why you didn't do the same for the MCV vs MCV case? * A few typos: lenght -> length. - Heikki
В списке pgsql-hackers по дате отправления: