Re: Selectivity estimation for inet operators

From: Heikki Linnakangas <hlinnakangas(at)vmware(dot)com>
To: Emre Hasegeli <emre(at)hasegeli(dot)com>, Dilip kumar <dilip(dot)kumar(at)huawei(dot)com>
Cc: PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>, Andreas Karlsson <andreas(at)proxel(dot)se>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Subject: Re: Selectivity estimation for inet operators
Date: 2014-08-28 12:55:29
Message-ID: 53FF26C1.2070000@vmware.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Kyotaro HORIGUCHI 2014-08-28 13:01:18 Re: alter user set local_preload_libraries.
Previous Message Kyotaro HORIGUCHI 2014-08-28 12:47:04 Re: Escaping from blocked send() reprised.