-
Notifications
You must be signed in to change notification settings - Fork 5.9k
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
expression, plan: support builtin aggregation function 'bit_or' #5145
Conversation
Hi contributor, thanks for your PR. This patch needs to be approved by someone of admins. They should reply with "/ok-to-test" to accept this PR for running test automatically. |
@spongedu Thanks! |
/run-all-tests |
/run-sqllogic-test |
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.
LGTM
store/tikv/coprocessor.go
Outdated
@@ -78,7 +78,7 @@ func (c *CopClient) supportExpr(exprType tipb.ExprType) bool { | |||
case tipb.ExprType_Case, tipb.ExprType_If, tipb.ExprType_IfNull, tipb.ExprType_Coalesce: | |||
return true | |||
// aggregate functions. | |||
case tipb.ExprType_Count, tipb.ExprType_First, tipb.ExprType_Max, tipb.ExprType_Min, tipb.ExprType_Sum, tipb.ExprType_Avg: | |||
case tipb.ExprType_Count, tipb.ExprType_First, tipb.ExprType_Max, tipb.ExprType_Min, tipb.ExprType_Sum, tipb.ExprType_Avg, tipb.ExprType_Agg_BitOr: |
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.
TiKV doesn't support ExprType_Agg_BitOr.
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.
@shenli how about this:
- Step1: disable
FinalMode
forBIT_OR
so that it's not calculated in TIKV. - Step2: take another pr in TiKV to support
BIT_OR
IN TIKV. - Step3: re-enable
FinalMode
forBIT_OR
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.
If the agg is bit_or, we return c.store.mock
so as to push it to mock tikv instead of real tikv.
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.
- you mean that
BIT_OR
is never push down toTiKV
, even in real clustered environment? - This pr seems works ok with mock-tikv
- I think it's still necessary to support
BIT_OR
in TiKV anyway
what do you think
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.
After tikv has supported this aggregate function, we can remove this check. This is only a protection mechanism.
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.
ok
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.
@hanfei1991 PTAL. I disabled FinalMode
for aggregation BIT_OR
. This check seems can be removed
Conflicts: ast/functions.go expression/aggregation/agg_to_pb.go expression/aggregation/aggregation.go expression/integration_test.go plan/physical_plans.go
/run-all-tests |
/run-integration-common-test |
expression/aggregation/bit_or.go
Outdated
ft := types.NewFieldType(mysql.TypeLonglong) | ||
ft.Flen = 21 | ||
types.SetBinChsClnFlag(ft) | ||
ft.Flag |= mysql.UnsignedFlag |
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.
Do we need to add the flag of not null
?
mysql> select bit_or(b) from t;
Field 1: `bit_or(b)`
Catalog: `def`
Database: ``
Table: ``
Org_table: ``
Type: LONGLONG
Collation: binary (63)
Length: 21
Max_length: 1
Decimals: 0
Flags: NOT_NULL UNSIGNED BINARY NUM
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.
@zimulala yes. The same for BIT_AND
and BIT_XOR
.
expression/aggregation/bit_or.go
Outdated
// GetResult implements Aggregation interface. | ||
func (bf *bitOrFunction) GetResult(ctx *AggEvaluateContext) (d types.Datum) { | ||
d.SetUint64(ctx.Value.GetUint64()) | ||
return d |
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 not return "ctx.Value" directly?
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.
By cursoriness.... Will fix
expression/aggregation/bit_or.go
Outdated
if ctx.Value.IsNull() { | ||
ctx.Value.SetUint64(0) | ||
} | ||
v := row.GetUint64(0) |
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 here is 0?
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.
@zimulala you mean the 0
in line 83? what's wrong with it ?
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.
Yep. I don't know why the column index is 0.
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.
Besides, can we handle the operation of Update
use this same way in different modes?
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.
@zimulala yes, for bit_or
, bit_and
, bit_xor
, FinalMode
and Complete
mode seem act the same , I'll refine here.
@zimulala merge |
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.
Rest LGTM
|
||
// CalculateDefaultValue implements Aggregation interface. | ||
func (bf *bitOrFunction) CalculateDefaultValue(schema *expression.Schema, ctx context.Context) (d types.Datum, valid bool) { | ||
arg := bf.Args[0] |
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 we also check len(bf.Args[0]) as line 62?
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.
@shenli actually I think the check in line 62
should be removed as well. There's no need check argument length everytime Update
is called. Parser would fail if argument number is wrong unless something is wrong in the framework. Or we can do this check in expression/aggregation/aggregation.go
LGTM |
/run-all-tests |
/run-sqllogic-test |
1 similar comment
/run-sqllogic-test |
support builtin aggregation function 'bit_or'