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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
