-
Notifications
You must be signed in to change notification settings - Fork 891
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Implement vectorized filters #5915
Conversation
182d44b
to
ca60216
Compare
@erimatnor, @gayyappan: please review this pull request.
|
Since this is all about integer expressions, the numeric naming might be a bit misleading since there is also a numeric datatype for which none of this applies. |
Floats as well. What options do we have, "numerical" or maybe "arithmetic"? The postgres numeric probably won't be vectorized because its data structure is not practical (varlena header, another header, two representations, several special values, and it's stored as decimal digits). In other computation engines they use fixed-point, fixed-width decimals stored as binary, which are easily vectorized. |
I'd like to see some more tests (even if we dont initially support them)
|
@akuzm Do we have some benchmark data for this PR? |
if (OidIsValid(commutator_opno)) | ||
{ | ||
o->opno = commutator_opno; | ||
o->opfuncid = InvalidOid; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
why does this need to be InvalidOid
instead of get_opcode(commutator_opno);
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I am also not sure about the opfuncid
. However, in CommuteOpExpr
the opfuncid
is also set to InvalidOid
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Right, I think there's no particular reason, just repeating the CommuteOpExpr. I added a comment about this.
I'll rerun it, because there were some changes in main and now the comparison looks weird. |
Codecov Report
@@ Coverage Diff @@
## main #5915 +/- ##
==========================================
+ Coverage 81.34% 81.37% +0.02%
==========================================
Files 243 246 +3
Lines 55971 56193 +222
Branches 12395 12457 +62
==========================================
+ Hits 45532 45726 +194
Misses 8095 8095
- Partials 2344 2372 +28
... and 41 files with indirect coverage changes 📣 We’re building smart automated test selection to slash your CI/CD build times. Learn more |
There's 10-70% speedup on some analytical queries. The huge regression seems to be a flaky parallel plan. |
Added some simple tests for these cases to |
|
||
#include "pred_vector_const_arithmetic_type_pair.c" | ||
|
||
/* int4. functions. */ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nit:
/* int4. functions. */ | |
/* int4... functions. */ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I removed all these semicolons.
|
||
OpExpr *o = castNode(OpExpr, qual); | ||
|
||
if (list_length(o->args) != 2) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Could we have a test case for this case?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Added a case with unary operator.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Added a few minor comments, but overall it looks good.
@@ -0,0 +1,68 @@ | |||
-- This file and its contents are licensed under the Timescale License. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
can we have explain output here currently it is not visible from test output whether vectorized filters are actually used here. also can we have some tests with NULL e.g. col < NULL
, col <> NULL
, col IS NULL
, ...
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
- EXPLAIN would require versioned references, to avoid this I use the guc
debug_require_vector_qual
to check that the vectorized quals are used or not. NullTest
is not vectorized currently, I added cases foris null
andis not null
.- For null values in the column itself, I have tests with the
metric4
column. - Not sure how to test
col < NULL
because all the functions we vectorize are strict, and we don't vectorize the initplan parameters yet.
src/guc.c
Outdated
@@ -725,6 +736,22 @@ _guc_init(void) | |||
/* assign_hook= */ NULL, | |||
/* show_hook= */ NULL); | |||
|
|||
DefineCustomEnumVariable(/* name= */ "timescaledb.debug_require_vector_qual", | |||
/* short_desc= */ | |||
"ensure that non-vectorized filters are used in DecompressChunk node", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
should this be vectorized instead of non-vectorized?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It does both, depending on the setting. I'll make it say vectorized or non-vectorized
.
Start with supporting "vector ? const" predicates for several arithmetic type pairs.
6ef942d
to
c066d3f
Compare
Start with supporting "vector ? const" predicates for several arithmetic type pairs.
Disable-check: force-changelog-file