From: | Ron Snyder <snyder(at)roguewave(dot)com> |
---|---|
To: | 'Stephan Szabo' <sszabo(at)megazone23(dot)bigpanda(dot)com>, Ron Snyder <snyder(at)roguewave(dot)com> |
Cc: | "'pgsql-general(at)postgresql(dot)org'" <pgsql-general(at)postgresql(dot)org> |
Subject: | Re: Unexplainable slow down... |
Date: | 2002-03-15 02:32:51 |
Message-ID: | F888C30C3021D411B9DA00B0D0209BE8026E2DC5@cvo-exchange.cvo.roguewave.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
> >
> > OK, I'm now more confused. What do I do next to figure out why
> > postgres isn't choosing the better query? We're running a vacuum
> > analyze every
> > night-- do I need to tweak the weights so that seq_scan is
> less likely?
>
> Hmm, I'm not sure what the best answer is for this, it's
> getting beyond my depth. I'd guess that it's possible that
> it's over estimating the number of reads necessary to do the
> index scan because the rows are clustered together which
> would make it over-estimate the index scan cost and/or it
> could be underestimating the cost of the sequence scan/limit
> set as well (for example if the rows you want are late in the
> table it's going to underestimate the final cost I think.)
Hmm, I don't if it would be related, but the data only grows.
Additionally, we (about a week ago) migrated all of this data
(via pg_dump/pg_restore) from 7.1.3. Perhaps this is related?
Thanks again for all the help!
-ron
From | Date | Subject | |
---|---|---|---|
Next Message | Orion Henry | 2002-03-15 04:01:45 | Questions with the planner |
Previous Message | Dave | 2002-03-15 01:59:22 | pg_hba.conf |