-
Notifications
You must be signed in to change notification settings - Fork 6
Support field references #192
Comments
Investigation on design/breakdown first. |
postgres=# explain Update DISTRICT SET D_NEXT_O_ID = D_NEXT_O_ID + 1 WHERE D_W_ID = 1 AND D_ID = 2;
|
YBCPgExpr YBCNewEvalExprCall(YBCPgStatement ybc_stmt,
} |
bool YBCExecuteUpdate(Relation rel,
} |
|
For example for the function in the described SQL: opfuncid 177, it was { 177, "int4pl", 2, true, false, int4pl }, which was defined in int.c
as follows Datum
} |
The logic for YB to decide whether it should pushdown functions are as follows as in ybcplan.c /*
as we could see, it checks whether the function is a built-in one and then it is not a Polymorhipc pseduo-types (e.g. anyarray), which may require additional processing (requiring syscatalog access) to fully resolve to a concrete type. The built-in function check was in fmgr.h/.c, which defines the Postgres function manager and function-call interface. bool /*
static const FmgrBuiltin *
} The fmgr_builtin_oid_index was populated by the files such as fmgroids.h, fmgrprotos.h, and fmgrtab.c generated by src/backend/utils/Gen_fmgrtab.pl from pg_proc.dat. |
PG supports Create Function to define a custom function https://www.postgresql.org/docs/11/sql-createfunction.html Seems YB also supports that https://docs.yugabyte.com/latest/api/ysql/the-sql-language/statements/ddl_create_function/ Need to find out how the functions including custom ones are evaluated in YB's DocDB. |
The mechanism for YB's Docdb to eval the function is
That is to say, YB's Docdb has dependency on a submode of PG, e.g., ybgate_api. ybgate_api.h #ifdef __cplusplus /*
/*
/*
/*
|
ybgate_api.c #include "postgres.h" #include <setjmp.h> #include "ybgate/ybgate_api.h" #include "catalog/pg_type.h" struct YbgExprContextData The expr eval logic is in the following tree walk logic. /*
where FunctionCallInvoke was defined in fmgr.h /*
|
Have discussed how Docdb evals the function/expr, let take a look at how the docdb handles the function/expr calls. doc_expr.cc
where bfpg::TSOpcode::kPgEvalExprCall maps to PgExpr opcode Opcode::PG_EXPR_EVAL_EXPR_CALL. docdb_pgapi.cc Status DocPgEvalExpr(const std::string& expr_str, char *expr_cstring = const_cast<char *>(expr_str.c_str()); // Create the context expression evaluation. for (int i = 1; i < params.size(); i++) { PG_RETURN_NOT_OK(YbgExprContextCreate(min_attno, max_attno, &expr_ctx)); // Set the column values (used to resolve scan variables in the expression).
} // Evaluate the expression and get the result. // Assuming first arg is the target column, so using it for the return type. Status s = PgValueToPB(ret_type, datum, is_null, result); |
where YbgEvalExp was defined in ybgate_api.c YbgStatus YbgEvalExpr(char* expr_cstring, YbgExprContext expr_ctx, uint64_t *datum, bool *is_null) Obviously, the PG internal Expr node/subtree was deserialized from the expr string, then evalExpr was called to walk the tree to eval the expr node/subtree. The final result, datum, was returned. |
disabled the function pushdown for now by the following PR and will add support after k2 platform adds such support. |
e.g. UPDATE X SET Field1 = Field2 + 1 WHERE pkf1=1 AND pkf2=2;
The text was updated successfully, but these errors were encountered: