Re: GiST support for inet datatypes

On 01/19/2014 11:10 AM, Emre Hasegeli wrote:
>> I am not convinced an adjacent operator is useful for the inet type, but if
>> it is included it should be indexed just like -|- of ranges. We should try
>> to keep these lists of indexed operators the same.
>
> I added it just not to leave negotor field empty. It can also be useful with
> exclusion constraints but not with GiST support. I did not add GiST support
> for it and the not equals operator because they do not fit the index
> structure. I can just remove the operator for now.

Sounds good. None of the other && implementations have a negator.

>> I think it would be fine just to add the newly indexed operators here, but
>> the more indexed operators we get in the core the less useful this test
>> becomes.
>
> I did not add the new operators to the list because I do not feel right
> about supporting <<, <<=, >>, >>= symbols for these operators.
> They should be <@, <@=, @>, @>= to be consistent with other types.

I agree, but I am not sure if it is ok to break backward compatibility here.

>> -- Check that all opclass search operators have selectivity estimators.
>>
>> Fails due to missing selectivity functions for the operators. I think you
>> should at least for now do like the range types and use areajoinsel,
>> contjoinsel, etc for the join selectivity estimation.
>
> I did not support them in the first version because I could not decide
> the way. I have better options than using the the geo_selfuncs for these
> operators. The options are from simple to complex:
>
> 0) just use network_overlap_selectivity
> 1) fix network_overlap_selectivity with a constant between 0 and 1
> 2) calculate this constant by using masklens of all buckets of the histogram
> 3) calculate this constant by using masklens of matching buckets of
> the histogram
> 4) store STATISTIC_KIND_RANGE_LENGTH_HISTOGRAM for this
> types, calculate this constant with it
> 5) create another kind of histogram for masklens, calculate this constant
> with it
>
> I do not know how to do 4 or 5, so I will try 3 for the next version. Do you
> think it is a good idea?

Solutions 0 and 1 does not really sound better than using geo_selfuncs.

--
Andreas Karlsson