Hello,
I have a simple query as follows. It joins two very straightforward tables.
SELECT
trades.id,
trades.url,
trades.alias,
tradecount.t_count,
tradecount.u_count
FROM trades
LEFT JOIN tradecount ON trades.id = tradecount.id
WHERE trades.user_id = 'jondoe' and trades.status = 'Y'
On Sep 1, 2007, at 11:46, Phoenix Kiula wrote:
Hello,
I have a simple query as follows. It joins two very straightforward
tables.
SELECT
trades.id,
trades.url,
trades.alias,
tradecount.t_count,
tradecount.u_count
FROM trades
LEFT JOIN tradecount ON trades.id = tradecount.id
On 01/09/07, Alban Hertroys [EMAIL PROTECTED] wrote:
On Sep 1, 2007, at 11:46, Phoenix Kiula wrote:
.
..snip
However, there's a nested loop in there as the EXPLAIN ANALYZE shows
below. What is causing this nested loop?
It looks like it's used to match trades to tradecounts. I think
On Sep 1, 2007, at 14:48, Phoenix Kiula wrote:
On 01/09/07, Alban Hertroys [EMAIL PROTECTED] wrote:
On Sep 1, 2007, at 11:46, Phoenix Kiula wrote:
.
..snip
However, there's a nested loop in there as the EXPLAIN ANALYZE shows
below. What is causing this nested loop?
It looks like
Phoenix Kiula [EMAIL PROTECTED] writes:
On 01/09/07, Alban Hertroys [EMAIL PROTECTED] wrote:
Is 10 ms problematic for this query?
I think you got 10ms from the query plan? These queries are very fast
after they have been executed once. But the first time is huge.
Sometimes I have to wait as
Alban Hertroys [EMAIL PROTECTED] writes:
I am kind of surprised that the planner doesn't understand that a
foreign key with a unique constraint (which a primary key is) means
there is a 0..1 to 1 relationship with the target table.
Hm? It correctly estimated that it'd get one row out for
