From: Andrew Sullivan <ajs@crankycanuck.ca>
To: pgsql-sql@postgresql.org
Subject: Re: Sequence vs. Index Scan
Date: Sat, 5 May 2007 20:40:53 -0400
Message-ID: <20070506004053.GA22890@phlogiston.dyndns.org> (raw)
In-Reply-To: <bf05e51c0705051500p3e3de711na0d76ae1ad463775@mail.gmail.com>
References: <bf05e51c0705051405p29ee139fn30c9979f3772a1d4@mail.gmail.com>
<20070505213009.GA22573@phlogiston.dyndns.org>
<bf05e51c0705051500p3e3de711na0d76ae1ad463775@mail.gmail.com>
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
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-sql@postgresql.org
Cc: ajs@crankycanuck.ca
Subject: Re: Sequence vs. Index Scan
In-Reply-To: <20070506004053.GA22890@phlogiston.dyndns.org>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox