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?
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? |