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
alreadycode 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
maintenancewould be an issue (it's not like uint's change...).
--
Jim C. Nasby, Data Architect jim@nasby.net
512.569.9461 (cell) http://jim.nasby.net