Date: Fri, 11 Jan 2008 16:40:48 -0500
From: Michael Stone <mstone+postgres@mathom.us>
Subject: Re: Best way to index IP data?
In-reply-to: <20080111213204.GV5294@mathom.us>
To: pgsql-performance@postgresql.org
Mail-followup-to: pgsql-performance@postgresql.org
Message-id: <20080111214047.GW5294@mathom.us>
MIME-version: 1.0
Content-type: text/plain; charset=us-ascii; format=flowed
Content-disposition: inline
References: <200801101614.54729.kevin@kevinkempterllc.com>
	<DA6DE53A-2F69-46F3-8C96-B341ADCDDFAF@blighty.com>
	<36e682920801101541o7626bbddj428617144240c554@mail.gmail.com>
	<Pine.LNX.4.64.0801111025390.30762@localhost>
	<13179.1200064791@sss.pgh.pa.us>
	<20080111162747.GT5294@mathom.us> <24044.1200082058@sss.pgh.pa.us>
	<20080111151935.40c8d2fd.darcy@druid.net>
	<20080111213204.GV5294@mathom.us>
User-Agent: Mutt/1.5.13 (2006-08-11)

On Fri, Jan 11, 2008 at 04:32:05PM -0500, Michael Stone wrote:
>On Fri, Jan 11, 2008 at 03:19:35PM -0500, D'Arcy J.M. Cain wrote:
>>Besides, there are many cases where you want to track both ipv4 and
>>ipv6 for the same purpose and requiring two different fields would be
>>less than ideal.
>
>And, there are many cases where you don't. I've got two kinds of db's 
>that have IPs in them. In some, the IP is a small part of a table which 
>is focused on something else. For those I use inet, which provides a 
>nice bit of future-proofing. In other db's the IPs are the primary 
>focus. There are lots and lots of IPs, and the space used by IPs may be 
>the largest chunk of a particular table. For those tables, I don't use 
>inet because the overhead really is a significant fraction of the space.

Oh, yeah, the latter type also has seperate IPv4 and IPv6 tables, 
because there's no point in bloating 99% of the data for the 1% that's 
IPv6. Is that a niche requirement? Maybe--but I think that storing 
netmasks is even *more* of a niche...

I'm not arguing for the removal of inet, but I do think there's room for 
more than one type--and I certainly think its nuts to pretend that inet 
can meet every requirement well.

Mike Stone