From: Tom Lane <tgl@sss.pgh.pa.us>
To: Rick Otten <rottenwindfish@gmail.com>
cc: Mariel Cherkassky <mariel.cherkassky@gmail.com>,
        PostgreSQL mailing lists <pgsql-performance@postgresql.org>
Subject: Re: postgresql 10.1 wrong plan in when using partitions bug
In-reply-to: 
 <CAMAYy4KT-xvP6Q7iBvW5YAmmcrzpyTfACaLdjKn_tTvLNUu9+w@mail.gmail.com>
References: 
 <CA+t6e1m54jrEj7spf9ArH5BJiO-Qznn=_YCRGWWMtohvXg7mEg@mail.gmail.com>
 <CAMAYy4KT-xvP6Q7iBvW5YAmmcrzpyTfACaLdjKn_tTvLNUu9+w@mail.gmail.com>
Comments: In-reply-to Rick Otten <rottenwindfish@gmail.com>
	message dated "Sun, 04 Feb 2018 07:15:24 -0500"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <15449.1517758532.1@sss.pgh.pa.us>
Date: Sun, 04 Feb 2018 10:35:32 -0500
Message-ID: <15450.1517758532@sss.pgh.pa.us>
Precedence: bulk

Rick Otten <rottenwindfish@gmail.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