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

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

From: Edoardo Ceccarelli <eddy(at)axa(dot)it>
To: pg(at)fastcrypt(dot)com
Cc: Christopher Kings-Lynne <chriskl(at)familyhealth(dot)com(dot)au>,"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-27 21:42:58
Message-ID: 408ED3E2.802@axa.it (view raw or flat)
Thread:
Lists: pgsql-adminpgsql-jdbcpgsql-performance
I am going to use them as primary key of the table, so I'll surely need 
them unique :)
thank you for you help
Edoardo

Dave Cramer ha scritto:

>Edoardo, 
>
>Are you using them for referential integrity? If so you would be wise to
>use sequences instead. 
>
>Christopher: yes you are correct, I wasn't sure if that is what he was
>doing.
>
>Dave
>On Tue, 2004-04-27 at 11:01, Christopher Kings-Lynne wrote:
>  
>
>>>AFAIK, oids aren't used for anything internally, so duplicates don't
>>>really matter. Besides, what would you do about duplicate oid's ?
>>>      
>>>
>>If he's using them _externally_, then he does have to worry about 
>>duplicates.
>>
>>Chris
>>
>>
>>
>>!DSPAM:408e75e0137721921318500!
>>
>>
>>    
>>

In response to

Responses

pgsql-performance by date

Next:From: AteszDate: 2004-04-27 21:56:07
Subject: Re: Simply join in PostrgeSQL takes too long
Previous:From: Vitaly BelmanDate: 2004-04-27 21:27:40
Subject: Simply join in PostrgeSQL takes too long

pgsql-admin by date

Next:From: Jim SeymourDate: 2004-04-27 21:50:03
Subject: Re: Recover data
Previous:From: Eduardo NaschenwengDate: 2004-04-27 20:21:31
Subject: Optimizer choosing smaller index instead of right one

pgsql-jdbc by date

Next:From: Christopher Kings-LynneDate: 2004-04-28 01:30:44
Subject: Re: [JDBC] [PERFORM] is a good practice to create an index on the
Previous:From: Kris JurkaDate: 2004-04-27 19:05:47
Subject: Re: setCatalog

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