Teodor, could you check if this patch fixes your real-world problem?
It works fine with original query, thank you. But some other query slowdowns for
~10% (9 secs vs 10 secs). Look at following part of plans of huge query:
without patch:
-> Nested Loop (cost=34.82..50.91 rows=1 width=20)
(actual time=0.017..0.061 rows=5 loops=24121)
-> ...
-> Materialize (cost=0.56..15.69 rows=1 width=5)
(actual time=0.003..0.004 rows=2 loops=109061)
-> Index Scan using ... (cost=0.56..15.68 rows=1 width=5)
(actual time=0.013..0.014 rows=2 loops=24121)
with patch:
-> Nested Loop (cost=34.82..50.91 rows=1 width=20)
(actual time=0.018..0.063 rows=5 loops=24121)
-> ...
-> Index Scan using ... (cost=0.56..15.68 rows=1 width=5)
(actual time=0.012..0.013 rows=2 loops=109061)
(dots hidden the same parts)
As you said, it removes Materialize node, although it's useful here.
If you wish, I can do a test suite, its size will be around 10MB and send it by
private email.
--
Teodor Sigaev E-mail: teo...@sigaev.ru
WWW: http://www.sigaev.ru/
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
