From: | Ron Johnson <ron(dot)l(dot)johnson(at)cox(dot)net> |
---|---|
To: | PgSQL Performance ML <pgsql-performance(at)postgresql(dot)org> |
Subject: | Re: bigserial vs serial - which one I'd have to use? |
Date: | 2003-01-27 09:18:41 |
Message-ID: | 1043659121.815.407.camel@haggis |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
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(dot)l(dot)johnson(at)cox(dot)net |
| Jefferson, LA USA http://members.cox.net/ron.l.johnson |
| |
| "Fear the Penguin!!" |
+---------------------------------------------------------------+
From | Date | Subject | |
---|---|---|---|
Next Message | Shridhar Daithankar | 2003-01-27 09:45:07 | Re: LOCK TABLE & speeding up mass data loads |
Previous Message | Ron Johnson | 2003-01-27 09:08:20 | Re: LOCK TABLE & speeding up mass data loads |