Support not(expr) for build_predicate_expression

[xudong963]

Which issue does this PR close?

• Closes #.

Rationale for this change

Currently, we only support not(column), supporting more not expr could enhance the pruning

What changes are included in this PR?

Are these changes tested?

YES

Are there any user-facing changes?

[adriangb]

My main concern is correctness. I remember from working on the LIKE expression pruning after banging my head against the wall for a long time with failing fuzz tests I came to the conclusion that you can’t just NOT the pruning predicate itself. But I don’t have any specific cases to point to, I’d have to think about it for a bit.

[xudong963]

My main concern is correctness. I remember from working on the LIKE expression pruning after banging my head against the wall for a long time with failing fuzz tests I came to the conclusion that you can’t just NOT the pruning predicate itself. But I don’t have any specific cases to point to, I’d have to think about it for a bit.

I'm also trying to find some cases

[adriangb]

A thought experiment: the result of the pruning predicate has two states:

• true: some rows in this container may match -> can’t prune
• false: no rows in this container match -> can prune

If we apply NOT we get:

• false: some rows in this container may not match, ie some rows in this container may match -> can’t prune
• true: all rows in this container match -> can’t prune

[xudong963]

A thought experiment: the result of the pruning predicate has two states:

• true: some rows in this container may match -> can’t prune
• false: no rows in this container match -> can prune

If we apply NOT we get:

• false: some rows in this container may not match, ie some rows in this container may match -> can’t prune
• true: all rows in this container match -> can’t prune

yes, makese sense, thank you