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

From Dilip kumar
Subject Re: Selectivity estimation for inet operators
Date
Msg-id 4205E661176A124FAF891E0A6BA913526634320B@szxeml509-mbs.china.huawei.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  (Emre Hasegeli <emre@hasegeli.com>)
List pgsql-hackers
On 12 July 2014 23:25, Emre Hasegeli Wrote,

> > I have one last comment, after clarifying this I can move it to
> "ready for committer".
> > 1. In networkjoinsel, For avoiding the case of huge statistics, only
> some of the values from mcv and histograms are used (calculated using
> SQRT).
> > -- But in my opinion, if histograms and mcv both are exist then its
> fine, but if only mcv's are there in that case, we can match complete
> MCV, it will give better accuracy.
> >    In other function like eqjoinsel also its matching complete MCV.
> 
> I was not sure of reducing statistics, at all.  I could not find any
> other selectivity estimation function which does this.  After testing
> it some more, I reached the conclusion that it would be better to only
> reduce the values of the outer loop on histogram match.  Now it matches
> complete MCV lists to each other.  I also switched back to
> log2() from sqrt() to make the outer list smaller.

OK

> 
> I rethink your previous advice to threat histogram bucket partially
> matched when the constant matches the last boundary, and changed it
> that way.  It is better than using the selectivity for only one value.
> Removing this part also make the function more simple.  The new version
> of the patch attached.
This seems good to me.

> 
> While looking at it I find some other small problems and fixed them.
> I also realized that I forgot to support other join types than inner
> join.  Currently, the default estimation is used for anti joins.
> I think the patch will need more than trivial amount of change to
> support anti joins.  I can work on it later.  While doing it, outer
> join selectivity estimation can also be improved.  I think the patch is
> better than nothing in its current state.

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".

Regards,
Dilip




pgsql-hackers by date:

Previous
From: Abhijit Menon-Sen
Date:
Subject: Re: pg_shmem_allocations view
Next
From: Kyotaro HORIGUCHI
Date:
Subject: Re: Use unique index for longer pathkeys.