ance of the second
query (aside from changing the join order manually)?
select version();
version
------
PostgreSQL 8.0.3 on i486-pc-linux-gnu, compiled by GCC cc (GCC) 4.0.2 20050821
(prerelease) (Debian 4.0.1-6)
Thanks
--
- Rich Doughty
---(end of broadcast)---
TIP 2: Don't 'kill -9' the postmaster
Tom Lane wrote:
Rich Doughty <[EMAIL PROTECTED]> writes:
EXPLAIN SELECT *
FROM
tokens.ta_tokens t LEFT JOIN
tokens.ta_tokenhist h1 ON t.token_id = h1.token_id LEFT JOIN
tokens.ta_tokenhist h2 ON t.token_id = h2.token_id
WHERE
h1.histdate = 'now';
Tom Lane wrote:
Rich Doughty <[EMAIL PROTECTED]> writes:
Tom Lane wrote:
The reason these are different is that the second case constrains only
the last-to-be-joined table, so the full cartesian product of t and h1
has to be formed. If this wasn't what you had in mind, you might
where
((sarreport_id)::integer = 9). it thinks there are 53430 when in fact
there are only 7 (despite a vacuum and analyse).
Can anyone give me any suggestions? are the index stats the cause of
my problem, or is it the rewrite of the query?
Cheers
Version: PostgreSQL 8.0.3 on i486-pc-linux-gnu, compiled by GCC cc (GCC) 4.0.2
20050821 (prerelease) (Debian 4.0.1-6)
--
- Rich Doughty
---(end of broadcast)---
TIP 4: Have you searched our list archives?
http://archives.postgresql.org
Tom Lane wrote:
Rich Doughty <[EMAIL PROTECTED]> writes:
However, the following query (which i believe should be equivalent)
SELECT *
FROM
tokens.ta_tokenhist h INNER JOIN
tokens.ta_tokens t ON h.token_id = t.token_id LEFT JOIN
tokens.ta_tokenhist
what will perform better; a view that filters,
manipulates, and orders the data from the first view or a view that
performs all the necessary calculations on the original tables?
from personal experience, if the inner views contain outer joins performance
isn't that great.
--
- Rich Do
