Re: improve select performance...

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Steve Holdoway <steve(dot)holdoway(at)firetrust(dot)com>
Cc: pgsql-admin(at)postgresql(dot)org
Subject: Re: improve select performance...
Date: 2007-05-19 17:58:53
Message-ID: 14600.1179597533@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-admin

Steve Holdoway <steve(dot)holdoway(at)firetrust(dot)com> writes:
> I managed to get this working properly by dropping the index on the
> url column, and making it the primary key instead. Can anyone point me
> at docs that define the difference between a primary key and an unique
> index on the same field? I'm a bit confused here!

A primary key is a unique index plus a not-null constraint on its
column(s), plus it's the default reference target for FOREIGN KEY
references to the table (which is why there can be only one per table).
AFAIK that's it. For the purposes of SELECTs there really is no
difference.

>> db=> \d badurls
..
>> Indexes:
>> "idxbadurls_url" hash (url)
>> "idxbadurls_version" btree (version)

One problem here is you used a hash index. Postgres' hash index
implementation is pretty poor. I suspect that the explicit marking
of the index as unique might've changed the plan too; it's fairly
obvious from your EXPLAIN that the planner didn't previously know
the column was unique. (Which suggests that you oughta ANALYZE
more often.)

regards, tom lane

In response to

Browse pgsql-admin by date

  From Date Subject
Next Message Ritu Khetan 2007-05-21 10:51:28 Logging query for Postgresql 8.1
Previous Message Steve Holdoway 2007-05-19 02:51:45 Re: improve select performance...