Skip to content

Conversation

@tustvold
Copy link
Contributor

@tustvold tustvold commented Jul 4, 2023

Which issue does this PR close?

Part of #6842

Rationale for this change

Using ScalarValue to store a boolean is just inefficient and wasteful

What changes are included in this PR?

Are these changes tested?

Are there any user-facing changes?

@github-actions github-actions bot added the physical-expr Changes to the physical-expr crates label Jul 4, 2023
Comment on lines 225 to 229
/// new bool_and accumulator
pub fn try_new(data_type: &DataType) -> Result<Self> {
Ok(Self {
bool_and: ScalarValue::try_from(data_type)?,
})
assert_eq!(data_type, &DataType::Boolean);
Ok(Self { acc: None })
}
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If you just assert the DataType to be one constant value, then you can also just remove the parameter and return Self.

Copy link
Contributor

@alamb alamb left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Seems fine to me -- thank you @tustvold

@Dandandan and I have but plans for those aggregates anyways (though we won't get rid of the need for a ScalarValue based version)

Copy link
Member

@jackwener jackwener left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks @tustvold

@tustvold tustvold merged commit a1281aa into apache:main Jul 6, 2023
alamb pushed a commit to alamb/datafusion that referenced this pull request Jul 6, 2023
* Deprecate ScalarValue::and, ScalarValue::or (apache#6842)

* Review feedback
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

physical-expr Changes to the physical-expr crates

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants