Thomas Munro writes:
> On Wed, Mar 14, 2018 at 2:56 PM, Jeff Janes wrote:
>> Is there any good way to make the regression tests fail if the plan reverts
>> to the bad one? The only thing I can think of would be to make the table
>> bigger so the regression tests becomes "noticeably slower", but
On Wed, Mar 14, 2018 at 2:56 PM, Jeff Janes wrote:
> On Tue, Mar 13, 2018 at 4:57 PM, Thomas Munro
> wrote:
>> Here's a patch to remove LIMIT 1, which fixes the plan for Jeff's test
>> scenario and some smaller and larger examples I tried. The query is
>> already executed with SPI_execute(..., 1
On Tue, Mar 13, 2018 at 4:57 PM, Thomas Munro wrote:
> On Wed, Mar 14, 2018 at 12:29 PM, Tom Lane wrote:
> > Thomas Munro writes:
> >> There is a fundamental and complicated estimation problem lurking here
> >> of course and I'm not sure what to think about that yet. Maybe there
> >> is a very
On Wed, Mar 14, 2018 at 12:29 PM, Tom Lane wrote:
> Thomas Munro writes:
>> There is a fundamental and complicated estimation problem lurking here
>> of course and I'm not sure what to think about that yet. Maybe there
>> is a very simple fix for this particular problem:
>
> Ah, I see you though
Thomas Munro writes:
> There is a fundamental and complicated estimation problem lurking here
> of course and I'm not sure what to think about that yet. Maybe there
> is a very simple fix for this particular problem:
Ah, I see you thought of the same hack I did.
I think this may actually be a g
Thomas Munro writes:
> This looks like an invisible correlation problem.
Yeah --- the planner has no idea that the join rows satisfying
newdata.* *= newdata2.* are likely to be exactly the ones not
satisfying newdata.ctid <> newdata2.ctid. It's very accidental
that we got a good plan before.
I'
On Wed, Mar 14, 2018 at 11:34 AM, Thomas Munro
wrote:
> LOG: duration: 26101.612 ms plan:
> Query Text: SELECT newdata FROM pg_temp_3.pg_temp_16452 newdata WHERE
> newdata IS NOT NULL AND EXISTS (SELECT * FROM pg_temp_3.pg_temp_16452
> newdata2 WHERE newdata2 IS NOT NULL AND newdata2
> OPERATOR(
On Wed, Mar 14, 2018 at 8:07 AM, Jeff Janes wrote:
> The following commit has caused a devastating performance regression
> in concurrent refresh of MV:
>
> commit 7ca25b7de6aefa5537e0dbe56541bc41c0464f97
> Author: Tom Lane
> Date: Wed Nov 29 22:00:29 2017 -0500
>
> Fix neqjoinsel's behavio