Thread: bigserial vs serial - which one I'd have to use?
Hi all, 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. Thanks in advance for your help. Gabor
On Sun, 2003-01-26 at 15:24, Medve Gabor wrote: > Hi all, > > 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. I think you can only do LIKE queries on CHAR-type fields. BETWEEN ought to help you, though: SELECT * FROM foo where prim_key BETWEEN YYYYMMDD00000000 and YYYYMMDD999999999; Alternatively, if you really want to do 'YYYYMMDD%', you could create a functional index on to_char(prim_key). Lastly, you could create 2 fields and create a compound PK: PK_DATE DATE, PK_SERIAL BIGINT Then you could say: SELECT * FROM foo where pk_date = 'YYYY-MM-DD' Of course, then you'd be adding an extra 8 bytes to each column... -- +---------------------------------------------------------------+ | Ron Johnson, Jr. mailto:ron.l.johnson@cox.net | | Jefferson, LA USA http://members.cox.net/ron.l.johnson | | | | "Fear the Penguin!!" | +---------------------------------------------------------------+
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
On Mon, 2003-01-27 at 13:33, Josh Berkus wrote: > 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 Ah, cool. I thought DATE was 8 bytes. Should have RTFM, of course. > INT + SERIAL (INT) = 8 bytes > > CHAR(16) = 18 bytes -- +---------------------------------------------------------------+ | Ron Johnson, Jr. mailto:ron.l.johnson@cox.net | | Jefferson, LA USA http://members.cox.net/ron.l.johnson | | | | "Fear the Penguin!!" | +---------------------------------------------------------------+