Re: failing to use index on UNION of matviews (Re: postgresql 10.1wrong plan in when using partitions bug)

Поиск
Список
Период
Сортировка
От Rick Otten
Тема Re: failing to use index on UNION of matviews (Re: postgresql 10.1wrong plan in when using partitions bug)
Дата
Msg-id CAMAYy4JBdm_g_m5B67jgz58tqKu+KyNDjQ_OkBotTubK+jkzRw@mail.gmail.com
обсуждение исходный текст
Ответ на Re: failing to use index on UNION of matviews (Re: postgresql 10.1wrong plan in when using partitions bug)  (Rick Otten <rottenwindfish@gmail.com>)
Список pgsql-performance


Setting enable_seqscan=off takes one of the shorter queries I was working with from about 3 minutes to 300ms.   This is a comparable performance improvement to where I put a materialized view (with indexes) on top of the materialized views instead of using a simple view on top of the materialized views.  I'll have to try it with the query that takes 12 hours.



The query that takes 12 hours and won't use indexes when I feel it should is a materialized view refresh.  When I set it before testing the plan with a simple explain on the query it definitely gets it to use all of the indexes.  Does setting something like "enable_seqscan=off" work when I follow it with a "refresh materialized view concurrently" instead of a simple select?   I'll try it to see if it helps the refresh time, but I thought I'd ask.

(I got pulled into another problem since my last email, so I haven't had a chance to follow up.)


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

Предыдущее
От: "Alex Ignatov"
Дата:
Сообщение: RE: pg_xlog unbounded growth
Следующее
От: Vitaliy Garnashevich
Дата:
Сообщение: Re: effective_io_concurrency on EBS/gp2