Skip site navigation (1) Skip section navigation (2)

Re: [HACKERS] cidr'

From: Bruce Momjian <maillist(at)candle(dot)pha(dot)pa(dot)us>
To: tgl(at)sss(dot)pgh(dot)pa(dot)us (Tom Lane)
Cc: pgsql-hackers(at)hub(dot)org
Subject: Re: [HACKERS] cidr'
Date: 1998-07-21 15:45:18
Message-ID: 199807211545.LAA29635@candle.pha.pa.us (view raw or flat)
Thread:
Lists: pgsql-hackers
> Bruce Momjian <maillist(at)candle(dot)pha(dot)pa(dot)us> writes:
> >> Would it make sense to use atttypmod to distinguish several different
> >> subtypes of CIDR?  "4 bytes", "4 bytes + mask", "6 bytes", "6 bytes
> >> + mask" seem like interesting possibilities.
> 
> > Yes, that is the proper way to go, though atttypmod is something on
> > column, not on each data row.  It is specified when the column is
> > created.
> 
> Right, that's what I had in mind.  If you *know* that every entry in
> your table only needs IPv4, you can specify that when making the table
> and save a couple of bytes per entry.
> 
> The alternative solution is to make CIDR a variable-length type, but
> I think the overhead of that would be as much or more than the possible
> savings, no?
> 
> I don't know whether having multiple top-level types would be better
> or worse than one type with a subtype code.

The byte size is really not an issue to me.  You can do ip6 and still
put it in eight bytes.  If you make it a variable-lengh type, you have
the length on each field, and that is four bytes right there, so you are
better doing eight bytes from the start.

	ip4	5 btyes(4 + precision)
	ip6	7 bytes(6 + precision)

If you want ip6 now, just take eight bytes and make it a fixed length. 
The backend it going to round the disk storage of 5 bytes up to eight
anyway, unless the next field is int2 or char1.

-- 
Bruce Momjian                          |  830 Blythe Avenue
maillist(at)candle(dot)pha(dot)pa(dot)us              |  Drexel Hill, Pennsylvania 19026
  +  If your life is a hard drive,     |  (610) 353-9879(w)
  +  Christ can be your backup.        |  (610) 853-3000(h)

In response to

pgsql-hackers by date

Next:From: Bruce MomjianDate: 1998-07-21 15:47:40
Subject: Re: Complexity of contrib types
Previous:From: Hannu KrosingDate: 1998-07-21 15:31:00
Subject: Re: Complexity of contrib types

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group