Re: Selectivity estimation for inet operators - Mailing list pgsql-hackers

From Heikki Linnakangas
Subject Re: Selectivity estimation for inet operators
Date
Msg-id 53FF26C1.2070000@vmware.com
Whole thread Raw
In response to Re: Selectivity estimation for inet operators  (Emre Hasegeli <emre@hasegeli.com>)
Responses Re: Selectivity estimation for inet operators
Re: Selectivity estimation for inet operators
List 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 by date:

Previous
From: Kyotaro HORIGUCHI
Date:
Subject: Re: Escaping from blocked send() reprised.
Next
From: Kyotaro HORIGUCHI
Date:
Subject: Re: alter user set local_preload_libraries.