Tom Lane wrote:
Kim Bisgaard <[EMAIL PROTECTED]> writes:
The reason the first query is not performing is because the query
optimizer does not push the conditions down into the sub-queries - right??
Well, it's not the same condition: the WHERE clause is constraining
the output variable
Kim Bisgaard <[EMAIL PROTECTED]> writes:
> The reason the first query is not performing is because the query
> optimizer does not push the conditions down into the sub-queries - right??
Well, it's not the same condition: the WHERE clause is constraining
the output variable of the FULL JOIN, which
Hi Tom,
I have now completed the move to PG8.0.3, and feel that I have confirmed
that this problem is related to the problem I'm having:
Formulated like this, it is not performing:
SELECT station_id, timeobs,temp_grass, temp_dry_at_2m
FROM temp_dry_at_2m a
FULL OUTER JOIN temp_gra
Hi Tom,
This sounds like the same "problem" which prevented PG from using the
indices, and thus giving abyssmal performance in this other thread:
I have two BIG tables (virtually identical) with 3 NOT NULL columns
Station_id, TimeObs, Temp_, with unique indexes on (Station_id,
TimeObs) a
Tom Lane wrote:
Phil Endecott <[EMAIL PROTECTED]> writes:
D join (M join G on (M.g=G.id)) on (D.id=M.b) where D.id=nnn
A possible workaround is to generate your query like
D left join (M join G on (M.g=G.id)) on (D.id=M.b AND M.b=nnn) where D.id=nnn
I don't suppose it would work if I did
Phil Endecott <[EMAIL PROTECTED]> writes:
> I don't see anything in there about LEFT OUTER JOIN though. Any ideas?
Oh, I missed that part of your message. Hmm, I think the issue is that in
>> D join (M join G on (M.g=G.id)) on (D.id=M.b) where D.id=nnn
the planner deduces M.b=nnn by transitivi
Tom Lane wrote:
Phil Endecott <[EMAIL PROTECTED]> writes:
I have a number of complex views for which the typical use is to select
exactly one row by id, e.g. "select * from V where id=nnn". Some of
these selects run orders of magnitude faster than others. Looking at
the output of "explain
Phil Endecott <[EMAIL PROTECTED]> writes:
> I have a number of complex views for which the typical use is to select
> exactly one row by id, e.g. "select * from V where id=nnn". Some of
> these selects run orders of magnitude faster than others. Looking at
> the output of "explain analyse" it
