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

Re: [JDBC] [PERFORM] is a good practice to create an index on the

From: Bruno Wolff III <bruno(at)wolff(dot)to>
To: Edoardo Ceccarelli <eddy(at)axa(dot)it>
Cc: Christopher Kings-Lynne <chriskl(at)familyhealth(dot)com(dot)au>,pg(at)fastcrypt(dot)com,"pgsql-jdbc(at)postgresql(dot)org" <pgsql-jdbc(at)postgresql(dot)org>,pgsql-performance(at)postgresql(dot)org, pgsql-admin(at)postgresql(dot)org
Subject: Re: [JDBC] [PERFORM] is a good practice to create an index on the
Date: 2004-04-28 08:32:23
Message-ID: 20040428083223.GA8384@wolff.to (view raw or flat)
Thread:
Lists: pgsql-adminpgsql-jdbcpgsql-performance
On Wed, Apr 28, 2004 at 10:13:14 +0200,
  Edoardo Ceccarelli <eddy(at)axa(dot)it> wrote:
> do you mean that, declaring an index serial, I'd never have to deal with 
> incrementing its primary key? good to know!

That isn't what is happening. Serial is a special type. It is int plus
a default rule linked to a sequence. No index is created by default
for the serial type. Declaring a column as a primary key will however
create a unique index on that column.

Also note that you should only assume that the serial values are unique.
(This assumes that you don't use setval and that you don't roll a sequence
over.) Within a single session you can assume the sequence values will
be monotonicly increasing. The values that end up in your table can have
gaps. Typically this happens when a transaction rolls back after obtaining
a new value from a sequence. It can also happen if you grab sequence
values in larger blocks (which might be more efficient if a session normally
acquires mulitple values from a particular sequence) than the default 1.

> anyway  in this particular situation I don't need such accurate 
> behaviour: this table is filled up with a lot of data twice per week and 
> it's used only to answer queries.
> I could drop it whenever I want :)

You really don't want to use oids.

In response to

pgsql-performance by date

Next:From: Rod TaylorDate: 2004-04-28 12:23:35
Subject: Re: Simply join in PostrgeSQL takes too long
Previous:From: Christopher Kings-LynneDate: 2004-04-28 08:25:26
Subject: Re: [JDBC] [PERFORM] is a good practice to create an index on the

pgsql-admin by date

Next:From: Ben KimDate: 2004-04-28 15:46:54
Subject: parametrized query
Previous:From: Christopher Kings-LynneDate: 2004-04-28 08:25:26
Subject: Re: [JDBC] [PERFORM] is a good practice to create an index on the

pgsql-jdbc by date

Next:From: Brian OlsonDate: 2004-04-28 15:26:35
Subject: v3 from the ground up
Previous:From: Christopher Kings-LynneDate: 2004-04-28 08:25:26
Subject: Re: [JDBC] [PERFORM] is a good practice to create an index on the

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