Re: [PERFORM] bad performance - Mailing list pgsql-performance

From Tom Lane
Subject Re: [PERFORM] bad performance
Date
Msg-id 23585.1482015858@sss.pgh.pa.us
Whole thread Raw
In response to [PERFORM] bad performance  (Gabliver Faluker <gabliver@gmail.com>)
Responses Re: [PERFORM] bad performance  (Jeremy Harris <jgh@wizmail.org>)
List pgsql-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


pgsql-performance by date:

Previous
From: Gabliver Faluker
Date:
Subject: [PERFORM] bad performance
Next
From: Dinesh Chandra 12108
Date:
Subject: Re: [PERFORM] Size of Temporary tablespace is increasing very much inpostgresql 9.1.