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

Re: Do non-sequential primary keys slow performance significantly??

From: Bruno Wolff III <bruno(at)wolff(dot)to>
To: Richard Broersma Jr <rabroersma(at)yahoo(dot)com>
Cc: Damian C <jamianb(at)gmail(dot)com>, pgsql-novice(at)postgresql(dot)org
Subject: Re: Do non-sequential primary keys slow performance significantly??
Date: 2006-09-30 02:41:17
Message-ID: 20060930024117.GA7919@wolff.to (view raw or flat)
Thread:
Lists: pgsql-generalpgsql-novice
On Fri, Sep 29, 2006 at 08:10:23 -0700,
  Richard Broersma Jr <rabroersma(at)yahoo(dot)com> wrote:
> > The most difficult part of this question is justifying WHY we would
> > want to use random primary keys!  There is a very strong reason for
> > doing so, although not quite compelling.
> 
> One problem with using random generated primary keys that I've
> recently read about deal with insert failing do to primary key
> duplication.
> 
> If the size of your dataset grows to become a significant percentage
> of the size of the integer type used for your random primary key,
> the probability of inserting a duplicated number dramatically
> increases.  I imagine that this problem could contribute to poor
> preformance for large bulk inserts that have to add logic for 
> dealing with re-trying a insert if a duplicate number is created.

They are using 128 bit keys! If their random number generator actually
works, they shouldn't have a problem until they have generated on the order
of 2^64 keys. That isn't likely to happen any time soon.

In response to

pgsql-novice by date

Next:From: Jan DanielssonDate: 2006-09-30 18:34:05
Subject: Potentially annoying question about date ranges
Previous:From: Frances CollierDate: 2006-09-29 21:24:44
Subject: Re: Cancelled statement due to lost connection

pgsql-general by date

Next:From: Ken JohansonDate: 2006-09-30 04:46:57
Subject: Re: PG Rocks! (was:Backslashes in 8.2 still escape, hwo
Previous:From: Jeff DavisDate: 2006-09-30 00:39:05
Subject: Re: Backslashes in 8.2 still escape, hwo to disable?

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