Medve,
> Have you got any data (ie in percentage) of around how much more CPU
> work needed with the bigserial type in the queries?
>
> I have a log database with 100million records (the biggest table
> contains 65million records) and I use bigserial data type as primary key
> now. The primary key looks this way: YYYYMMDD1xxxxxxx where the first 8
> numbers are the date, and the x's are the record sequence number on that
> day. This way the records are in ascendant order. Almost all of the
> queries contains date constraints (PK like 'YYYYMMDD%'). I'd like to
> know if I do it in a stupid way or not. I'm not a DBA expert so every
> idea are welcome. If you need more information about the
> hardware/software environment, the DB structure then I'll post them.
Given that structure, I'd personally create a table with a 2-column primary
key, one column of type DATE and one SERIAL column. Alternately, if you find
the conversion of DATE to char for output purposes really slows things down,
one column of INT and one of SERIAL. Either way, the two columns together
make up the primary key.
I would definitely suggest avoiting the temptation to do this as a single
column of type CHAR(). That would be vastly more costly than either
strategy mentioned above:
DATE + SERIAL (INT) = 8 bytes
INT + SERIAL (INT) = 8 bytes
CHAR(16) = 18 bytes
--
-Josh Berkus
Aglio Database Solutions
San Francisco
