| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Gabliver Faluker <gabliver(at)gmail(dot)com> |
| Cc: | pgsql-performance(at)postgresql(dot)org |
| Subject: | Re: bad performance |
| Date: | 2016-12-17 23:04:18 |
| Message-ID: | 23585.1482015858@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-performance |
Gabliver Faluker <gabliver(at)gmail(dot)com> writes:
> It runs for ~5 seconds .
I'm a little skeptical that a 12-way join producing 340K rows
and executing in 5 seconds should be considered "bad performance".
It looks like it'd help some if you increased work_mem enough to let
both sorts happen in-memory rather than externally. But really, this
is going to take awhile no matter what. Do you really need all 340K
rows of the result? Can you improve your data representation so that
you don't need to join quite so many tables to get the answer, and
(probably even more importantly) so that you don't need to use
SELECT DISTINCT? The sort/unique steps needed to do DISTINCT are
eating a large part of the runtime, and they also form an optimization
fence IIRC.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Dinesh Chandra 12108 | 2016-12-19 09:19:18 | Re: Size of Temporary tablespace is increasing very much in postgresql 9.1. |
| Previous Message | Gabliver Faluker | 2016-12-17 22:25:53 | bad performance |