Hi,
On 2019-02-22 16:27:28 -0500, Regina Obe wrote:
> > I think there are probably other ways of fixing this query that won't have
> > such dramatic effects; it doesn't really seem to need to use WITH, and I bet
> > you could also tweak the WITH query to prevent inlining.
>
> Yes I know I can c
On Fri, Feb 22, 2019 at 4:27 PM Regina Obe wrote:
> It's going to make a lot of people hesitant to upgrade if they think they
> need to revisit every CTE (that they intentionally wrote cause they thought
> it would be materialized) to throw in a MATERIALIZED keyword.
You might be right, but I h
> I think there are probably other ways of fixing this query that won't have
> such dramatic effects; it doesn't really seem to need to use WITH, and I bet
> you could also tweak the WITH query to prevent inlining.
Yes I know I can change THIS QUERY. I've changed other ones to work around
this
Andres Freund writes:
> On 2019-02-22 15:33:08 -0500, Regina Obe wrote:
>> The CTE change in PostgreSQL 12 broke several of PostGIS regression tests
>> because many of our tests are negative tests that test to confirm we get
>> warnings in certain cases. In the past, these would output 1 notice b
On Fri, Feb 22, 2019 at 3:33 PM Regina Obe wrote:
> Historically PostGIS functions haven't been costed right and can't be
> because they rely on INLINING of sql functions which gets broken when too
> high of cost is put on functions. We have a ton of functions like these
> that return composite o
Hi,
On 2019-02-22 15:33:08 -0500, Regina Obe wrote:
> The CTE change in PostgreSQL 12 broke several of PostGIS regression tests
> because many of our tests are negative tests that test to confirm we get
> warnings in certain cases. In the past, these would output 1 notice because
> the CTE was ma
