Re: Sequence vs. Index Scan - Mailing list pgsql-sql

From Andrew Sullivan
Subject Re: Sequence vs. Index Scan
Date
Msg-id 20070506004053.GA22890@phlogiston.dyndns.org
Whole thread Raw
In response to Re: Sequence vs. Index Scan  ("Aaron Bono" <postgresql@aranya.com>)
Responses Re: Sequence vs. Index Scan  ("Aaron Bono" <postgresql@aranya.com>)
List pgsql-sql
On Sat, May 05, 2007 at 05:00:53PM -0500, Aaron Bono wrote:
> 
> They have different data.  The fast one has about 150 rows and the  slow one
> has about 40 rows.  The field in question here, the branch_id, is a
> BIGSERIAL in both.

I'd be astonished if a table of 40 rows ever got index scanned.  It's
probably more efficient to read the whole table.  But it seems your
case may be strange.  

> We don't allow deletes and updates are fairly infrequent.  I also did a
> vacuum analyze to no effect.

How do you "not allow" deletes?  Does this happen because of a failed
foreign key?  If so, you can end up with dead tuples.  I'd look at
the output of VACUUM VERBOSE to make sure you don't have a lot of
dead tuples.  That said, I wonder if fiddling with the statistics on
your tables might help.

A

-- 
Andrew Sullivan  | ajs@crankycanuck.ca
In the future this spectacle of the middle classes shocking the avant-
garde will probably become the textbook definition of Postmodernism.                --Brad Holland


pgsql-sql by date:

Previous
From: Tom Lane
Date:
Subject: Re: Sequence vs. Index Scan
Next
From: "Aaron Bono"
Date:
Subject: Re: Sequence vs. Index Scan