From: Tom Lane <tgl@sss.pgh.pa.us>
To: Gabliver Faluker <gabliver@gmail.com>
Cc: pgsql-performance@postgresql.org
Subject: Re: bad performance
Date: Sat, 17 Dec 2016 18:04:18 -0500
Message-ID: <23585.1482015858@sss.pgh.pa.us> (raw)
In-Reply-To: <CAPy8Q=hoNQ1-D+CLOuRUFb7ujsO1z3hJWNKTgtFZT1XoDV_2Zw@mail.gmail.com>
References: <CAPy8Q=hoNQ1-D+CLOuRUFb7ujsO1z3hJWNKTgtFZT1XoDV_2Zw@mail.gmail.com>
List-Unsubscribe: <mailto:majordomo@postgresql.org?body=unsub%20pgsql-performance>
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
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-performance@postgresql.org
Cc: tgl@sss.pgh.pa.us, gabliver@gmail.com
Subject: Re: bad performance
In-Reply-To: <23585.1482015858@sss.pgh.pa.us>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox