From: | Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)com> |
---|---|
To: | Colin Watson <cjwatson(at)canonical(dot)com> |
Cc: | Andrew Gierth <andrew(at)tao11(dot)riddles(dot)org(dot)uk>, Michael Paquier <michael(at)paquier(dot)xyz>, pgsql-hackers(at)lists(dot)postgresql(dot)org |
Subject: | Re: Backport "WITH ... AS MATERIALIZED" syntax to <12? |
Date: | 2019-10-19 10:52:10 |
Message-ID: | 20191019105210.a26fv3xkmsi6teqa@development |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Sat, Oct 19, 2019 at 10:22:39AM +0100, Colin Watson wrote:
>On Sat, Oct 19, 2019 at 05:01:04AM +0100, Andrew Gierth wrote:
>> >>>>> "Michael" == Michael Paquier <michael(at)paquier(dot)xyz> writes:
>> > On Fri, Oct 18, 2019 at 02:21:30PM +0100, Colin Watson wrote:
>> >> However, an alternative would be to backport the new syntax to some
>> >> earlier versions. "WITH ... AS MATERIALIZED" can easily just be
>> >> synonymous with "WITH ... AS" in versions prior to 12; there's no
>> >> need to support "NOT MATERIALIZED" since that's explicitly
>> >> requesting the new query-folding feature that only exists in 12.
>> >> Would something like the attached patch against REL_11_STABLE be
>> >> acceptable? I'd like to backpatch it at least as far as PostgreSQL
>> >> 10.
>>
>> Michael> I am afraid that new features don't gain a backpatch. This is
>> Michael> a project policy. Back-branches should just include bug fixes.
>>
>> I do think an argument can be made for making an exception in this
>> particular case. This wouldn't be backpatching a feature, just accepting
>> and ignoring some of the new syntax to make upgrading easier.
>
>Right, this is my position too. I'm explicitly not asking for
>backpatching of the CTE-inlining feature, just trying to cope with the
>fact that we now have to spell some particular queries differently to
>retain the performance characteristics we need for them.
>
>I suppose an alternative would be to add a configuration option to 12
>that allows disabling inlining of CTEs cluster-wide: we could then
>upgrade to 12 with inlining disabled, add MATERIALIZED to the relevant
>queries, and then re-enable inlining. But I like that less because it
>would end up leaving cruft around in PostgreSQL's configuration code
>somewhat indefinitely for the sake of an edge case in upgrading to a
>particular version.
I think having a GUC option was proposed and discussed while developping
the feature, and it was rejected - one of the reasons being experience
with similar GUCs in the past, which essentially just allowed users to
postpone the fix indefinitely, and increased our maintenance burden.
I wonder if an extension could do something like that, though. It can
install a hook after parse analysis, so I guess it could walk the CTEs
and mark them as materialized.
regards
--
Tomas Vondra http://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
From | Date | Subject | |
---|---|---|---|
Next Message | Tomas Vondra | 2019-10-19 11:08:31 | Re: jsonb_set() strictness considered harmful to data |
Previous Message | Tomas Vondra | 2019-10-19 10:48:17 | Re: Backport "WITH ... AS MATERIALIZED" syntax to <12? |