Scott Cain <[EMAIL PROTECTED]> writes:
> Embarrassingly, I can't. I've been monkeying with the database so much
> that I can't seem to get it back to the state where I reproduce the
> behavior I want.
If the thing works as desired after a VACUUM ANALYZE, then I suggest
the estimation failure was
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
On Fri, 2003-07-11 at 11:36, Scott Cain wrote:
> Rod,
>
> I see what you mean about the scan on the feature_pkey taking a long
> time. I tried several things to remedy that. I created an index on
> feature (feature_id,type_id) (which I don't think makes sense since
> feature_id is the primary ke
Rod,
I see what you mean about the scan on the feature_pkey taking a long
time. I tried several things to remedy that. I created an index on
feature (feature_id,type_id) (which I don't think makes sense since
feature_id is the primary key, so add another column really doesn't
help). I also crea
The problem (at least as it appears to me) is not that it is performing
a table scan instead of an index scan, it is that it is using the wrong
index. Here is the output from EXPLAIN ANALYZE:
QUERY PLAN
-
Hi Tom,
Embarrassingly, I can't. I've been monkeying with the database so much
that I can't seem to get it back to the state where I reproduce the
behavior I want. A database drop and reload may be the only way, but
since that is a time consuming thing to do, I won't be able to do it
until this
Shridhar Daithankar wrote:
On 10 Jul 2003 at 0:43, Martin Foster wrote:
As for creating a new table, that in itself is a nice idea. But it
would cause issues for people currently in the realm. Their posts
would essentially dissapear from site and cause more confusion then its
worth.
No t
Scott Cain <[EMAIL PROTECTED]> writes:
> So, the question is, is there a way I can force the query planner to use
> the index I want it to use?
No (and I don't think there should be). Given that it *can* generate
the plan you want, this is clearly an estimation failure. What is the
index it does
