Re: Slow join using network address function

Tom Lane wrote:

>"Eric Jain" <Eric(dot)Jain(at)isb-sib(dot)ch> writes:
>
>
>>><http://word-to-the-wise.com/ipr.tgz> is a datatype that contains
>>>a range of IPv4 addresses, and which has the various operators to
>>>make it GIST indexable.
>>>
>>>
>
>
>
>>Great, this looks very promising.
>>
>>
>
>
>
>>>No cast operators between ipr and inet types.
>>>
>>>
>
>
>
>>Any way to work around this, short of dumping and reloading tables?
>>
>>
>
>Wouldn't it be better to implement the GIST indexing operators of that
>package on the standard datatypes? It wasn't apparent to me what "range
>of IP addresses" does for you that isn't covered by "CIDR subnet" for
>real-world cases.
>
> regards, tom lane
>
>---------------------------(end of broadcast)---------------------------
>TIP 8: explain analyze is your friend
>
>
We currently only allow access to one of our apps based on IP address.
These IPs are stored one per row in a single table, but often represent
a contiguous piece of IP space, but does not represent a full subnet.
The current CIDR subnet has the limitation that it will only allow full
subnets, i.e. every IP address in 192.168.1.0/24. For example:

192.168.1.15 -> 192.168.1.31

This range cannot be represented by a CIDR subnet, or it might be able
to but I really dont want to figure it out each time. However this new
type allows us to store this range as one row. It allows an arbitrary
range of IP addresses, not just those in a specific subnet. I would see
this as a useful inclusion whether in the main src tree or in contrib
and we will probably be using it when we get to "mess" with the database
schema for this app in the next few months, in fact I have already
inserted it into our PG source tree ;-).

Nick

P.S. We are not responsible for the IP address ranges, we just get told
what they are.