Horton

Re: neqjoinsel versus "refresh materialized view concurrently"

Tom Lane <tgl@sss.pgh.pa.us>

View thread View on postgr.es
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Thomas Munro <thomas.munro@enterprisedb.com>
Cc: Jeff Janes <jeff.janes@gmail.com>, pgsql-hackers <pgsql-hackers@postgresql.org>
Date: 2018-03-13T23:13:52Z
Lists: pgsql-hackers 
Thomas Munro <thomas.munro@enterprisedb.com> 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've not looked to see where this query is generated, but I wonder
if we could make things better by dropping the LIMIT 1 and instead
using an executor count parameter to stop early.

			regards, tom lane

Commits

  1. Fix performance hazard in REFRESH MATERIALIZED VIEW CONCURRENTLY.

  2. Fix neqjoinsel's behavior for semi/anti join cases.