Re: [PERFORM] bad performance

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: [PERFORM] bad performance
Дата
Msg-id 23585.1482015858@sss.pgh.pa.us
обсуждение исходный текст
Ответ на [PERFORM] bad performance  (Gabliver Faluker <gabliver@gmail.com>)
Ответы Re: [PERFORM] bad performance
Список 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 по дате отправления:

Предыдущее
От: Gabliver Faluker
Дата:
Сообщение: [PERFORM] bad performance
Следующее
От: Dinesh Chandra 12108
Дата:
Сообщение: Re: [PERFORM] Size of Temporary tablespace is increasing very much inpostgresql 9.1.