Re: postgresql 10.1 wrong plan in when using partitions bug

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Rick Otten <rottenwindfish(at)gmail(dot)com>
Cc: Mariel Cherkassky <mariel(dot)cherkassky(at)gmail(dot)com>, PostgreSQL mailing lists <pgsql-performance(at)postgresql(dot)org>
Subject: Re: postgresql 10.1 wrong plan in when using partitions bug
Date: 2018-02-04 15:35:32
Message-ID: 15450.1517758532@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

Rick Otten <rottenwindfish(at)gmail(dot)com> writes:
> I'm wrestling with a very similar problem too - except instead of official
> partitions I have a views on top of a bunch (50+) of unioned materialized
> views, each "partition" with 10M - 100M rows. On 9.6.6 the queries would
> use the indexes on each materialized view. On 10.1, every materialized
> view is sequence scanned.

Can you post a self-contained example of this behavior? My gut reaction
is that the changes for the partitioning feature broke some optimization
that used to work ... but it could easily be something else, too. Hard
to say with nothing concrete to look at.

> I'm mostly hoping with fingers crossed that something in 10.2, which is
> coming out next week, fixes it.

If you'd reported this in suitable detail awhile ago, we might have been
able to fix it for 10.2. At this point, with barely 30 hours remaining
before the planned release wrap, it's unlikely that anything but the most
trivial fixes could get done in time.

regards, tom lane

In response to

Responses

Browse pgsql-performance by date

  From Date Subject
Next Message Tom Lane 2018-02-04 15:39:11 Re: postgresql 10.1 wrong plan in when using partitions bug
Previous Message Mariel Cherkassky 2018-02-04 15:28:52 Re: postgresql 10.1 wrong plan in when using partitions bug