Le 16/03/2010 16:52, Tom Lane a écrit :
Sometime in the future they might generate the same plan. Right now the
planner's ability to optimize sub-SELECTs is pretty limited, and so you
typically get a nestloop-like plan even if some other join style would
be faster.
OK, thanks for the clarifica
Arnaud Lesauvage writes:
> I am still a bit intrigued by the different query plans. Both query look
> very similar to me, so why does the planner make so different choices ?
Sometime in the future they might generate the same plan. Right now the
planner's ability to optimize sub-SELECTs is pret
Le 16/03/2010 16:02, t...@fuzzy.cz a écrit :
I will try increasing work_mem, but it is already set at 16MB which I
found is quite high.
What do you mean by "high"? I believe the proper value of work_mem is such
that results in highest performance of the query while not causing
problems to the
Le 16/03/2010 15:37, Tom Lane a écrit :
Arnaud Lesauvage writes:
First query :
"Merge Join (cost=699826.38..704333.80 rows=13548 width=836)"
" Merge Cond: (((c.rue)::text = (r.rue)::text) AND ((c.codesite)::text
= (r.codesite)::text))"
Second query :
"Seq Scan on cellules c (cost=0.
> Le 16/03/2010 15:25, Richard Huxton a écrit :
>> OK - we have a merge join in the first case where it joins the
>> pre-sorted output of both tables.
>>
>> In the second case it queries the index once for each row in "cellules".
>>
>> Now look at the costs. The first one is around 704,000 and th
Le 16/03/2010 15:25, Richard Huxton a écrit :
OK - we have a merge join in the first case where it joins the
pre-sorted output of both tables.
In the second case it queries the index once for each row in "cellules".
Now look at the costs. The first one is around 704,000 and the second
one is 5,
Arnaud Lesauvage writes:
> First query :
> "Merge Join (cost=699826.38..704333.80 rows=13548 width=836)"
> " Merge Cond: (((c.rue)::text = (r.rue)::text) AND ((c.codesite)::text
> = (r.codesite)::text))"
> " -> Sort (cost=696320.21..697701.07 rows=552343 width=823)"
> "Sort Key: c.r
On 16/03/10 13:57, Arnaud Lesauvage wrote:
First query :
"Merge Join (cost=699826.38..704333.80 rows=13548 width=836)"
" Merge Cond: (((c.rue)::text = (r.rue)::text) AND ((c.codesite)::text =
(r.codesite)::text))"
" -> Sort (cost=696320.21..697701.07 rows=552343 width=823)"
" Sort Key: c.rue, c.
Le 16/03/2010 14:50, Richard Huxton a écrit :
On 16/03/10 13:05, Arnaud Lesauvage wrote:
PostgreSQL 8.4 here.
I have a simple update query that looks like this :
UPDATE t1
SET col = t2.col
FROM t2
WHERE t1.key1 = t2.key1 AND t1.key2 = t2.key2;
There is an index on (key1,key2) on the joi
On 16/03/10 13:05, Arnaud Lesauvage wrote:
Hi all !
PostgreSQL 8.4 here.
I have a simple update query that looks like this :
UPDATE t1
SET col = t2.col
FROM t2
WHERE t1.key1 = t2.key1 AND t1.key2 = t2.key2;
There is an index on (key1,key2) on the joined table (t2).
This query does not use the
10 matches
Mail list logo
