Gábor E. Gévay

Mostly done by https://github.com/MaterializeInc/materialize/pull/17937 A remaining todo is tracked in https://github.com/MaterializeInc/materialize/issues/18219

Just recording that it seems this can also manifest as a fail in `system-cluster.td`, if I'm reading things correctly here: https://buildkite.com/materialize/tests/builds/55213#018805d7-3d9b-4283-bd12-e06c709ae1fe

Note that we need the concept of _unchanging collection_, which doesn't change after timestamp `s`. We are not going to read at `[]`, so we need to be able to...

We'll get back to this later. Or maybe it could be considered as part of https://github.com/MaterializeInc/materialize/pull/27001, where more general occurrences of this problem are being discussed.

One more instance here in a user query: https://materializeinc.slack.com/archives/C02PPB50ZHS/p1675867461671029

(Might also help here: https://github.com/MaterializeInc/materialize/issues/19437, but it enables pushdowns into sources instead of eliminating cross joins.)

One more situation where the decomposition of an OR in a MirScalarExpr expr to a UNION in MirRelationExpr would help (came from @sthm): The following doesn't compile, because `mz_now` is...

This would also help the `NOT IN` issue (https://github.com/MaterializeInc/materialize/issues/1137).

I would say don't close it yet. The problem is that if the columns are not declared NOT NULL, then the plan still has the cross join: ``` Explained Query:...

Simpler repro: ``` CREATE TABLE t1 ( a int, b int ); CREATE TABLE t2 ( a int, b int ); explain select * from t1 where t1.a NOT IN...