You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@arrow.apache.org by "Weston Pace (Jira)" <ji...@apache.org> on 2022/02/01 21:03:00 UTC
[jira] [Created] (ARROW-15519) [C++] Investigate potential performance improvments for the filter node
Weston Pace created ARROW-15519:
-----------------------------------
Summary: [C++] Investigate potential performance improvments for the filter node
Key: ARROW-15519
URL: https://issues.apache.org/jira/browse/ARROW-15519
Project: Apache Arrow
Issue Type: Improvement
Components: C++
Reporter: Weston Pace
Right now some early runs with Arrowbench and the OT PR (https://github.com/apache/arrow/pull/12100) shows that we spend a fair amount of time in TPC-H queries on filter nodes. There are a few improvements we know could be made to our filtering approach at the moment. I'm creating this parent issue to help categorize and track those:
* We can use a selection vector in our filters to reduce the amount of materialization needed. While long term we may want to support a selection vector throughout the exec plan a good start would be to use it when we encounter a chain of filters to avoid excess materialization (e.g. x < 10 && x > 5 && y < 20)
* If a filter if very selective then we may end up outputting a lot of very small batches. We could probably hold onto the data at the filter node until we've accumulated enough rows for a decent sized batch.
* The filter node is currently creating new thread tasks instead of appending its work onto an existing thread task.
* If we have a chain of filters we could potentially use runtime selectivity statistics / estimates to reorder our filters so that the most selective filters are evaluated first.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)