This is interesting for two filters, I think visitFilter in ServerPlanRequestVisitor will override each other, so one predicate will be skipped.

this is not unexpected. (we can potentially make it more smart). the problem is that

WITH tmp1
     AS (SELECT *
         FROM   a
         WHERE  col2 NOT IN ( 'foo', 'bar' )),
     tmp2
     AS (SELECT *
         FROM   b
         WHERE  col1 IN (SELECT col1
                         FROM   tmp1)
                AND col3 < 100)
SELECT *
FROM   tmp2
WHERE  col1 IN (SELECT col1
                FROM   tmp1  -- this is the tmp1 modification into tmp1'
                WHERE  col3 > 10) 

at this stage

• Calcite's doesn't know if you want to do a table spool of tmp1 and make tmp1' derived from tmp1 --> thus col3 > 10 is not pushed down.
• only when we decided that table spool is not possible and then we decided to copy tmp1 and tmp1' into 2 separate sub queries, at that time i think the hep optimizer already get passed the filter merging phase.

rewriting the query in this way

WITH tmp1
     AS (SELECT *
         FROM   a
         WHERE  col2 NOT IN ( 'foo', 'bar' )),
     tmp2
     AS (SELECT *
         FROM   b
         WHERE  col1 IN (SELECT col1
                         FROM   tmp1)
                AND col3 < 100),
     tmp3 -- here we explicitly tell that tmp3 and tmp1 are not related
     AS (SELECT *
         FROM   a
         WHERE  col2 NOT IN ( 'foo', 'bar' ) AND col3 > 10),
SELECT *
FROM   tmp2
WHERE  col1 IN (SELECT col1
                FROM   tmp3) 

produces no multi-filter plan

If we cannot avoid this, then it means the ServerPlanRequestVisitor should handle the leaf query generation properly.

this is a un-plannable sql before or after this bug fix PR. I would suggest differ the fix into a different PR (i will change the test to make sure it doesn't happen)