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

From Rick Otten
Subject Re: failing to use index on UNION of matviews (Re: postgresql 10.1wrong plan in when using partitions bug)
Date
Msg-id CAMAYy4JBdm_g_m5B67jgz58tqKu+KyNDjQ_OkBotTubK+jkzRw@mail.gmail.com
Whole thread Raw
In response to Re: failing to use index on UNION of matviews (Re: postgresql 10.1wrong plan in when using partitions bug)  (Rick Otten <rottenwindfish@gmail.com>)
List 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 by date:

Previous
From: "Alex Ignatov"
Date:
Subject: RE: pg_xlog unbounded growth
Next
From: Vitaliy Garnashevich
Date:
Subject: Re: effective_io_concurrency on EBS/gp2