slow query on multiple table join

From: tao tony <tonytao0505(at)outlook(dot)com>
To: "pgsql-zh-general(at)postgresql(dot)org" <pgsql-zh-general(at)postgresql(dot)org>, "pgsql-general(at)postgresql(dot)org" <pgsql-general(at)postgresql(dot)org>
Subject: slow query on multiple table join
Date: 2017-05-08 09:37:58
Message-ID: CY4PR13MB13846AADDD9B9C55473B3D2DAAEE0@CY4PR13MB1384.namprd13.prod.outlook.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

hi guys,

I met a query performance issue in postgresql 9.6.2 with multiple tables joined.

[cid:part1(dot)F9606D33(dot)54D41E1B(at)outlook(dot)com]

there were 2 slow queries,and the reasons were the same:the optimizer generate a bad explain which using nest loop.

attached is the query and its explain.all tables are small and the indexes were only created on primary keys .

in query 1 I noticed the explain forecast the nest loop anti join return 1 row as below,it was the result of (f join p) join pt:

[cid:part2(dot)B9424DDD(dot)2EC6D3D5(at)outlook(dot)com]

while in analyze explain,it actually returns 57458 row.so higher level nest loop would get 57458*1558 rows,this cause this query runs for more than 40 seconds.

[cid:part3(dot)6233EAD2(dot)99E4DB84(at)outlook(dot)com]

If I disabled nest loop,ti only use 519 ms.

in query 2 ,the nest loop join also process more than 200m rows,it runs almost 2 minutes.After disable nest loop,it use hash join,finished in 1.5 sec.

[cid:part4(dot)14AD365E(dot)F21D11F6(at)outlook(dot)com] please kindly let me know there's any solution to solve the problem,thanks a lot!

ps"table size for query 1:

[cid:part5(dot)39061AF3(dot)F36B715A(at)outlook(dot)com]

Attachment Content-Type Size
slow_query.txt text/plain 23.8 KB

Browse pgsql-general by date

  From Date Subject
Next Message Maxim Boguk 2017-05-08 12:52:09 Very suspicious plan difference for select and corresponding delete queries PostgreSQL 9.6.2
Previous Message Steve Atkins 2017-05-08 01:49:37 Re: Caching and Blobs in PG? Was: Can PG replace redis, amqp, s3 in the future?