Re: BUG #15102: Performance problem when doing join, index are not used - Mailing list pgsql-bugs

From Mehdi Rahman
Subject Re: BUG #15102: Performance problem when doing join, index are not used
Date
Msg-id CANV61G6j29cUmMrkTAJViB1j5V9g73aO9eDpdXj9C=nFdDRd0w@mail.gmail.com
Whole thread Raw
In response to Re: BUG #15102: Performance problem when doing join, index are not used  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-bugs
Hello,

Thanks a lot for your answer. I did change parameters and will retry the query.

I am sorry for posting in the bad list and will put any future performance questions at pgsql-performance.

Have a nice day,
Mehdi Rahman

2018-03-08 16:41 GMT+01:00 Tom Lane <tgl@sss.pgh.pa.us>:
PG Bug reporting form <noreply@postgresql.org> writes:
> Here is the query:
> [ select with 11 input tables ]

Perhaps raising join_collapse_limit to 11 or more would let the query
planner find a better plan.  Having said that, I see no especially good
reason to think that sort-and-merge isn't a good join type for this query.
Indexes aren't always the answer, especially not when joining large
numbers of rows as you are here.

Another direction to pursue is to raise work_mem to allow the sorts to
proceed more efficiently.  Don't go overboard on that, but judicious
increases can help.

Lastly, I see no reason whatever to think this is a bug.  You might
have better luck discussing the issue on the pgsql-performance list.

                        regards, tom lane

pgsql-bugs by date:

Previous
From: Michael Paquier
Date:
Subject: Re: BUG #15105: OpenTransientFile() should be paired withCloseTransientFile() rather than close()
Next
From: Tom Lane
Date:
Subject: Re: BUG #15105: OpenTransientFile() should be paired with CloseTransientFile() rather than close()