Bryce,
- I think that the difference between the two queries has to do with the
way postgresql execute them.
In the first the SGDB does:
1º Creates a temporary table with "m" X "n" rows where the "m" and
"n" are the number of the rows in the tables been joined.
2º Take only
Tom Lane wrote:
Why are the rowcount estimates so far off? Maybe you need to increase
the statistics target for this table.
regards, tom lane
Tom,
How does one tell the rowcount is off in a query plan? I've never
found a great reference on interpreting the query analyze output!
Upp
Bryce Nesbitt <[EMAIL PROTECTED]> writes:
> I'm a bit confused why the query planner is not restricting my join, and
> not using the index. Two explain analyze statements follow.
Why are the rowcount estimates so far off? Maybe you need to increase
the statistics target for this table.
Dear Postgres Folks,
I'm a bit confused why the query planner is not restricting my join, and
not using the index.
Two explain analyze statements follow. Why is the second so much better?
lyell5=> vacuum analyze;
lyell5=> select version();
PostgreSQL 8.3.4 on x86_64-pc-linux-gnu, compiled by GCC
I'm a bit confused why the query planner is not restricting my join, and
not using the index. Two explain analyze statements follow.
Why is the second so much better?
lyell5=> select version();
PostgreSQL 8.3.4 on x86_64-pc-linux-gnu, compiled by GCC cc (GCC) 4.1.2
20061115 (prerelease) (Debian 4
Hi,
I am trying to execute this query I wrote and it is not returning at a
reasonable time to the browser. I took the query and ran EXPLAIN on it
and it displayed that every JOIN I do it is doing a Seq Scan on it. I
have indexes on that table but it doesn't seem to use it.
Is there a way I can
