Re: Backport "WITH ... AS MATERIALIZED" syntax to <12?

From: Nikolay Samokhvalov <samokhvalov(at)gmail(dot)com>
To: Isaac Morland <isaac(dot)morland(at)gmail(dot)com>
Cc: Andrew Dunstan <andrew(dot)dunstan(at)2ndquadrant(dot)com>, Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)com>, Andres Freund <andres(at)anarazel(dot)de>, PostgreSQL Developers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Andrew Gierth <andrew(at)tao11(dot)riddles(dot)org(dot)uk>, Michael Paquier <michael(at)paquier(dot)xyz>, Colin Watson <cjwatson(at)canonical(dot)com>
Subject: Re: Backport "WITH ... AS MATERIALIZED" syntax to <12?
Date: 2019-10-19 21:04:43
Message-ID: CANNMO+Li+99kkYbTbP0pE15odSPC_e6b5u3_S6sqGDhfuGDApQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Sat, Oct 19, 2019 at 8:11 AM Isaac Morland <isaac(dot)morland(at)gmail(dot)com>
wrote:

> That embeds a temporary hack in the application code indefinitely.
>

Or postpone the migration indefinitely. I saw so many times how migration
in large companies was postponed because of similar "small" issues -- when
the code base is large, it's easier for managers to say something like "no,
we will better live without cool new features for a couple of more years
than put our systems at risk due to lack of testing".

Nobody invented an excellent way to test production workloads in
non-production environments yet. I know it very well because I'm also
working in this direction for a couple of years. So this feature (a great
one) seems to me as a major roadblock for DBAs and developers who would
like to migrate to 12 and have better performance and all the new features.
Ironically, including this one for the new or the updated code!

If you need to patch all your code adding "AS MATERIALIZED" (and you will
need it if you want to minimize risks of performance degradation after the
upgrade), then it's also a temporary hack. But much, much more expensive in
implementation in large projects, and sometimes even not possible.

I do think that the lack of this configuration option will prevent some
projects from migration for a long time.

Correct me if I'm wrong. Maybe somebody already thought about migration
options here and have good answers? What is the best way to upgrade if you
have dozens of multi-terabyte databases, a lot of legacy code and workloads
where 1 minute of downtime or even performance degradation would cost a lot
of money so it is not acceptable? What would be the good answers here?

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Andres Freund 2019-10-19 21:14:19 Re: Ordering of header file inclusion
Previous Message Nikolay Samokhvalov 2019-10-19 20:46:11 Re: Backport "WITH ... AS MATERIALIZED" syntax to <12?