From: | Scott Cain <cain(at)cshl(dot)org> |
---|---|
To: | Rod Taylor <rbt(at)rbt(dot)ca> |
Cc: | Postgresql Performance <pgsql-performance(at)postgresql(dot)org> |
Subject: | Re: force the use of a particular index |
Date: | 2003-07-11 18:23:04 |
Message-ID: | 1057947784.5767.39.camel@localhost.localdomain |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
On Fri, 2003-07-11 at 14:14, Rod Taylor wrote:
> > > set enable_hashjoin = false;
> >
> > BINGO!
>
> I'm not so sure about that. Your dataset seems to have changed fairly
> significantly since the last test.
>
> > -> Index Scan using feature_pkey on feature f (cost=0.00..134592.43 rows=47912 width=39) (actual time=0.46..502.50 rows=431 loops=1)
>
> Notice it only pulled out 431 rows where prior runs pulled out several
> thousand (~13000). I think what really happened was something came
> along and deleted a bunch of stuff, then vacuum ran.
There is nearly a zero chance that happened. This database is
accessible only by me, I haven't deleted anything. The only things I
have done is to create and drop various indexes and run vacuum. Is
there anything else that could explain the difference? Is the index
scan on feature_pkey using information from the index scan on
featureloc_src_6 to limit the number of rows to get from feature?
Scott
--
------------------------------------------------------------------------
Scott Cain, Ph. D. cain(at)cshl(dot)org
GMOD Coordinator (http://www.gmod.org/) 216-392-3087
Cold Spring Harbor Laboratory
From | Date | Subject | |
---|---|---|---|
Next Message | Martin Foster | 2003-07-12 02:17:34 | Optimizer Parameters |
Previous Message | Rod Taylor | 2003-07-11 18:14:45 | Re: force the use of a particular index |