Re: int4 vs varchar to store ip addr

From: "Michael Artz" <mlartz(at)gmail(dot)com>
To: "Pomarede Nicolas" <npomarede(at)corp(dot)free(dot)fr>
Cc: "Florian Weimer" <fweimer(at)bfk(dot)de>, pgsql-performance(at)postgresql(dot)org
Subject: Re: int4 vs varchar to store ip addr
Date: 2007-02-01 19:30:42
Message-ID: e9c163070702011130h184ed360p2956eba6bc49e2f0@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

On 1/30/07, Pomarede Nicolas <npomarede(at)corp(dot)free(dot)fr> wrote:
> On Mon, 29 Jan 2007, Florian Weimer wrote:
>
> > * Pomarede Nicolas:
> >
> >> I could use PG internal inet/cidr type to store the ip addrs, which
> >> would take 12 bytes per IP, thus gaining a few bytes per row.
> >
> > I thought it's down to 8 bytes in PostgreSQL 8.2, but I could be
> > mistaken.
> >
> >> Apart from gaining some bytes, would the btree index scan be faster
> >> with this data type compared to plain varchar ?
> >
> > It will be faster because less I/O is involved.
> >
> > For purposes like yours, there is a special ip4 type in a contributed
> > package which brings down the byte count to 4. I'm not sure if it's
> > been ported to PostgreSQL 8.2 yet.
>
> Yes thanks for this reference, ip4r package seems to be a nice addition to
> postgres for what I'd like to do. Does someone here have some real life
> experience with it (regarding performance and stability) ?

I'm using IP4 and have not had a problem with it in 8.2 (or 8.1) in
terms of stability. As I designed my DB using it, I don't really have
any comparisons to inet and/or varchar. One of the most useful things
for me is the ability to create a GIST index to support determination
of range inclusion (i.e. 192.168.23.1 is in the 192.168/16 network
range), although it doesn't sound like this would be useful to you.

-Mike

In response to

Browse pgsql-performance by date

  From Date Subject
Next Message Andrew Lazarus 2007-02-01 22:37:35 Re: Subselect query enhancement
Previous Message Michael Artz 2007-02-01 19:06:23 Re: Subselect query enhancement