feat: issue #9282 not creating page_pruning_predicate when pruning is…

[Lordworms]

… diable

Which issue does this PR close?

#9282

Closes #.

Rationale for this change

What changes are included in this PR?

Are these changes tested?

Are there any user-facing changes?

[Lordworms]

Could you help me to understand the impact of this change? From what I can tell, ParquetFormat::create_physical_plan() already checks this config before passing in the optional predicate, so this check seems redundant? Unless the intention is to centralize this check within ParquetExec::new() itself?

Yes, what I get from this issue is that @SteveLauC wants to centralize this check with ParquetExec::new()

[SteveLauC]

Well, centralizing the configuration to ParquetExec is not what I want, I simply don't want these 2 predicates to be created if the pushdowns are disabled.

Actually, does the issue described in #9282 really exist? I just gave another look at the calling procedure, it seems that if prune is disabled, then the predicate argument of ParquetExec::new() will be None, then these 2 predicates won't be created.

[SteveLauC]

Off-topic warning: the below behavior is not related to this PR

It seems that if prune is disabled, then filter pushdown will also be disabled as the predicate argument of ParquetExec::new() will be None.

[Lordworms]

It seems that if prune is disabled, then filter pushdown will also be disabled as the predicate argument of ParquetExec::new() will be None.

I know that. But I thought you want to centralized the check in ParquestExec::new(). lol

[SteveLauC]

For this PR and #9282, I am sorry that I opened an issue that actually does not exist:D

---

Off-topic warning: the below behavior is not related to this PR

It seems that if prune is disabled, then filter pushdown will also be disabled as the predicate argument of ParquetExec::new() will be None.

I am curious if this behavior is wanted?

[Jefffrey]

Off-topic warning: the below behavior is not related to this PR

It seems that if prune is disabled, then filter pushdown will also be disabled as the predicate argument of ParquetExec::new() will be None.

I am curious if this behavior is wanted?

This might be worth opening a new question issue for some more discussion on it? :thinking:

[alamb]

I am a little confused about what the status of this PR is -- is it still something we want to consider or have we decided it is not needed because https://github.com/apache/arrow-datafusion/issues/9282 was not a valid request?

[Lordworms]

Yes, I think it is not valid, I would close it