Scott Marlowe <smarlowe(at)g2switchworks(dot)com> writes:
> Secondly, it might be more efficient for the planner to choose the
> backup_location_rid index than the combination primary key index.
Oh, I'm an idiot; I didn't notice the way the index was set up. Yeah,
that index pretty well sucks for a query on backup_id --- it has to scan
the entire index, since there's no constraint on the leading column.
So that's where the time is going.
This combination of indexes:
> "backup_location_pkey" PRIMARY KEY, btree (record_id, backup_id)
> "backup_location_rid" btree (record_id)
is really just silly. You should have the pkey and then an index on
backup_id alone. See the discussion of multiple indexes in the fine
regards, tom lane
In response to
pgsql-performance by date
|Next:||From: Heikki Linnakangas||Date: 2007-05-18 20:19:00|
|Subject: Re: choosing fillfactor|
|Previous:||From: Andrew Kroeger||Date: 2007-05-18 20:05:41|
|Subject: Re: Slow queries on big table|