From: Tom Lane <tgl@sss.pgh.pa.us>
To: Gabliver Faluker <gabliver@gmail.com>
cc: pgsql-performance@postgresql.org
Subject: Re: bad performance
In-reply-to: 
 <CAPy8Q=hoNQ1-D+CLOuRUFb7ujsO1z3hJWNKTgtFZT1XoDV_2Zw@mail.gmail.com>
References: 
 <CAPy8Q=hoNQ1-D+CLOuRUFb7ujsO1z3hJWNKTgtFZT1XoDV_2Zw@mail.gmail.com>
Comments: In-reply-to Gabliver Faluker <gabliver@gmail.com>
	message dated "Sat, 17 Dec 2016 23:25:53 +0100"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <23584.1482015858.1@sss.pgh.pa.us>
Date: Sat, 17 Dec 2016 18:04:18 -0500
Message-ID: <23585.1482015858@sss.pgh.pa.us>
Precedence: bulk
Sender: pgsql-performance-owner@postgresql.org

Gabliver Faluker <gabliver@gmail.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


-- 
Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance