On Wed, Apr 17, 2019 at 11:16:28AM -0600, Michael Lewis wrote:
> > * Michael Lewis (mlewis@entrata.com) wrote:
> > > Thanks for that advance warning since it is a handy option to force the
> > > planning barrier in my experience. What's a resource to see other
> coming
> > > changes in v12 especially changes to default behavior like this? Will
> there
> > > be a new cte_collapse_limit setting or similar?
> >
> > Check the release notes.
>
> Yes, once they are written in a few weeks.
>
>
> Thanks for clarifying Bruce. On #postgresql I was directed to the development
> docs ( https://www.postgresql.org/docs/devel/queries-with.html ) and got the
> additional information I needed. It is unfortunate there is no MATERIALIZED
> keyword in v11 to ensure I can preserve existing behavior during upgrade to v12
> on queries that seem to benefit greatly from that optimization barrier, but I
> can appreciate why that decision was made.
Yes, there was a long discussions about it on IRC on April 3. There was
the idea that we could backpatch the MATERIALIZED keyword to PG 11 and
earlier and then users could change queries before upgrading to force
the existing behavior in PG 12. However, that is not without risk, and
Postgres has a tendency to just push such problems to the applications
rather than add complexity to the server:
https://momjian.us/main/blogs/pgblog/2019.html#February_25_2019
Here is discussion about adding a GUC to set the old behavior, but was
rejected:
https://www.postgresql.org/message-id/flat/000001d4caed%24d29b9ae0%2477d2d0a0%24%40pcorp.us
--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ As you are, so once was I. As I am, so you will be. +
+ Ancient Roman grave inscription +