From: | Andrew Sullivan <ajs(at)crankycanuck(dot)ca> |
---|---|
To: | pgsql-sql(at)postgresql(dot)org |
Subject: | Re: Sequence vs. Index Scan |
Date: | 2007-05-06 00:40:53 |
Message-ID: | 20070506004053.GA22890@phlogiston.dyndns.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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(at)crankycanuck(dot)ca
In the future this spectacle of the middle classes shocking the avant-
garde will probably become the textbook definition of Postmodernism.
--Brad Holland
From | Date | Subject | |
---|---|---|---|
Next Message | Aaron Bono | 2007-05-06 03:28:56 | Re: Sequence vs. Index Scan |
Previous Message | Tom Lane | 2007-05-06 00:22:50 | Re: Sequence vs. Index Scan |