Re: Perfomance bug in v10

From: Teodor Sigaev <teodor(at)sigaev(dot)ru>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, David Rowley <david(dot)rowley(at)2ndquadrant(dot)com>
Cc: Teodor Sigaev <teodor(at)postgrespro(dot)ru>, Pgsql Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Perfomance bug in v10
Date: 2017-06-02 12:24:05
Message-ID: 2bc8a109-ca43-cdc0-551f-e88e1478b3a0@sigaev.ru
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

>
> 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: teodor(at)sigaev(dot)ru
WWW: http://www.sigaev.ru/

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Hao Lee 2017-06-02 12:28:24 Re: Do we need the gcc feature "__builtin_expect" to promote the branches prediction?
Previous Message Robert Haas 2017-06-02 12:20:25 Re: make check false success