On 5/28/13 4:07 PM, Bruce Momjian wrote:
On Tue, May 28, 2013 at 11:17:42AM +0200, Maciej Gajewski wrote:
2. INTEGER
I had to store a record with several uint32. I had to store an awful
lot of them; hundreds GB of data per day. Roughly half of the record
consists of uint32 fields.
Increasing the data type to bigint would mean that I could store 3
instead of 4 days worth of data on available storage.
Continuing with int4 meant that I would have to deal with the data in
special way when in enters and leaves the DB. It's easy in C: just
cast uint32_t to int32_t. But python code requires more complex
changes. And the web backend too...
It's suffering either way!
Just imagine the conversation I had to have with my boss: "Either
we'll increase budged for storage, or we need to touch every bit of
the system".
Did you try 'oid' as an unsigned int4?
Using an internal catalog type for user data seems like a horrible idea to me...
I'll also add that Maciej hasn't explained why these types couldn't be an
extension (in fact, I'm pretty sure there's already code for this out there,
though possibly not utilizing the extension framework).
If you don't need implicit casting it should actually be pretty easy to do this
externally, and I don't think maintenance would be an issue (it's not like
uint's change...).
--
Jim C. Nasby, Data Architect j...@nasby.net
512.569.9461 (cell) http://jim.nasby.net
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
