Added to TODO:
* Sort large UPDATE/DELETEs so it is done in heap order
http://archives.postgresql.org/pgsql-hackers/2008-01/msg01119.php
---
Tom Lane wrote:
> We've had a couple of discussions recently revolving around
> At the planner level that would be entirely the wrong way to go about
> it, because that's forcing the equivalent of a nestloop join, which is
> very unlikely to be faster for the numbers of rows that we're talking
> about here. The reason it looks faster to you is that the benefits of
> updatin
"Stephen Denne" <[EMAIL PROTECTED]> writes:
> How hard is it to match, recognise potential benefit, and rewrite the query
> from
> UPDATE ONLY document_file AS df SET document_type_id =
> d.document_type_id FROM document AS d WHERE d.id = document_id;
> to
> UPDATE ONLY document_file A
> From: Tom Lane [mailto:[EMAIL PROTECTED]
> doubtless-oversimplified
It looks equivalent.
> With that patch, I got the results
...
>-> Hash Join (cost=123330.50..1207292.72 rows=408
> width=618) (actual time=20186.510..721120.455 rows=400 loops=1)
The plan from here is equivalent
We've had a couple of discussions recently revolving around the
inefficiency of using hashjoin/hashaggregation output to update a target
table, because of the resulting very random access pattern. I believe
this same mechanism is underlying the slowness of Stephen Denne's
"alternate query" describ
