Re: Egroupware infolog query slow (includes query plan)

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Egroupware infolog query slow (includes query plan)
Дата
Msg-id 17233.1215380067@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Egroupware infolog query slow (includes query plan)  (Mark Stosberg <mark@summersault.com>)
Список pgsql-sql
Mark Stosberg <mark@summersault.com> writes:
> I'm not skilled enough at reading the "Explain Analzyze" output to
> understand what the primary problem is. 

The problem is the repeated execution of the subquery in the SELECT
list; that's taking over 683 of the 686 seconds:

>                     SubPlan
>                       ->  Aggregate  (cost=2162.60..2162.61 rows=1
> width=0) (actual time=21.073..21.073 rows=1 loops=32424)                               ^^^^^^              ^^^^^

The current formulation of the query guarantees that you can't do better
than a nestloop join with "sub" on the inside, and that nestloop isn't
even indexed.  See if you can convert it to a regular join instead of a
sub-select (probably with GROUP BY instead of DISTINCT).

Also, those LIKE conditions are just horrid: slow *and* unreadable.
Consider redesigning your data representation.  Perhaps converting
info_responsible to an int array would be reasonable.
        regards, tom lane


В списке pgsql-sql по дате отправления:

Предыдущее
От: Mark Stosberg
Дата:
Сообщение: Re: Egroupware infolog query slow (includes query plan)
Следующее
От: dipesh
Дата:
Сообщение: How to find space occupied by postgres on harddisk