Skip site navigation (1) Skip section navigation (2)

Re: bigserial vs serial - which one I'd have to use?

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 (view raw, whole thread or download thread mbox)
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:
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:

Then you could say:
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  |
|                                                               |
| "Fear the Penguin!!"                                          |

In response to

pgsql-performance by date

Next:From: Shridhar DaithankarDate: 2003-01-27 09:45:07
Subject: Re: LOCK TABLE & speeding up mass data loads
Previous:From: Ron JohnsonDate: 2003-01-27 09:08:20
Subject: Re: LOCK TABLE & speeding up mass data loads

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group