Re: Slow join using network address function

Поиск
Список
Период
Сортировка
От Nick Barr
Тема Re: Slow join using network address function
Дата
Msg-id 403B7F89.5030902@chuckie.co.uk
обсуждение исходный текст
Ответ на Re: Slow join using network address function  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-performance
Tom Lane wrote:

>"Eric Jain" <Eric.Jain@isb-sib.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.





В списке pgsql-performance по дате отправления:

Предыдущее
От: "Jonathan M. Gardner"
Дата:
Сообщение: Materialized View Summary
Следующее
От: Josh Berkus
Дата:
Сообщение: Re: Column correlation drifts, index ignored again