Re: [PERFORM] Slow query after 9.3 to 9.6 migration

Поиск
Список
Период
Сортировка
От Gerardo Herzig
Тема Re: [PERFORM] Slow query after 9.3 to 9.6 migration
Дата
Msg-id 1769239108.5894902.1482893550894.JavaMail.root@fmed.uba.ar
обсуждение исходный текст
Ответ на [PERFORM] Slow query after 9.3 to 9.6 migration  (Flávio Henrique <yoshimit@gmail.com>)
Список pgsql-performance
>
> Hi there, fellow experts!
>
>
> I need an advice with query that became slower after 9.3 to 9.6
> migration.
>
>
> First of all, I'm from the dev team.
>
>
> Before migration, we (programmers) made some modifications on query
> bring it's average time from 8s to 2-3s.
>
>
> As this query is the most executed on our system (it builds the user
> panel to work), every bit that we can squeeze from it will be nice.
>
>
> Now, after server migration to 9.6 we're experiencing bad times with
> this query again.
>
>
> Unfortunately, I don't have the old query plain (9.3 version) to show
> you, but in the actual version (9.6) I can see some buffers written
> that tells me that something is wrong.
>
>
> Our server has 250GB of memory available, but the database team says
> that they can't do nothing to make this query better. I'm not sure,
> as some buffers are written on disk.
>
>
> Any tip/help will be much appreciated (even from the query side).
>
>
> Thank you!
>
>
> The query plan: https://explain.depesz.com/s/5KMn
>
>
> Note: I tried to add index on kilo_victor table already, but
> Postgresql still thinks that is better to do a seq scan.
>
>

I dont know about the data distribution in kilo_victor, but maybe a partial index
ON kilo_victor (juliet_romeo) where not xray_seven
?

Gerardo


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

Предыдущее
От: Valerii Valeev
Дата:
Сообщение: Re: [PERFORM] why we do not create indexes on master
Следующее
От: Daniel Blanch Bataller
Дата:
Сообщение: Re: [PERFORM] Slow query after 9.3 to 9.6 migration