From: | Jim Nasby <jim(at)nasby(dot)net> |
---|---|
To: | Brar Piening <brar(at)gmx(dot)de> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: smallserial / serial2 |
Date: | 2011-06-08 23:01:40 |
Message-ID: | 9A8C352E-B114-4477-846A-55B2E6055086@nasby.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Jun 8, 2011, at 5:36 PM, Brar Piening wrote:
> Pros
> Mike Pultz (patch author): "since serial4 and serial8 are simply pseudo-types- effectively there for convenience, I’d argue that it should simply be there for completeness"
> Robert Haas: "We should be trying to put all types on equal footing, rather than artificially privilege some over others."
> Brar Piening (me): "I'm with the above arguments. In addition I'd like to mention that other databases have it too so having it improves portability. Especially when using ORM."
> Perhaps we can get some more opinions...
We have some "dynamic lookup table" metacode that sets up all the infrastructure for a table that normalizes text values to a serial/int. But in many cases, it's a safe bet that we would never need more than 32k (or at worst, 64k) values. Right now it would be difficult to benefit from the 2 byte savings, but if Postgres was ever able to order fields on disk in the most efficient possible format (something we're willing to sponsor, hint hint ;) then this would be beneficial for us.
--
Jim C. Nasby, Database Architect jim(at)nasby(dot)net
512.569.9461 (cell) http://jim.nasby.net
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2011-06-08 23:29:42 | Re: smallserial / serial2 |
Previous Message | Alex Hunsaker | 2011-06-08 22:56:19 | Re: gcc 4.6 and hot standby |