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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 





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.)



[Postgresql General]     [Postgresql PHP]     [PHP Users]     [PHP Home]     [PHP on Windows]     [Kernel Newbies]     [PHP Classes]     [PHP Books]     [PHP Databases]     [Yosemite]

  Powered by Linux