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
Improve combine invocation analysis for user-defined aggregates #1990
Comments
combine
seems not work on user-define aggregate complex type.
@jchbh-duplicate thanks for your writeup! So internally there are actually a few things that go on implicitly in order for In addition to your main aggregate, you need another one that has the combine function as both the The main CREATE AGGREGATE numeric_avg(numeric) (
sfunc = numeric_avg_combine,
stype = internal,
finalfunc = numeric_avg,
combinefunc = numeric_avg_accum,
serialfunc = numeric_avg_serialize,
deserialfunc = numeric_avg_deserialize,
parallel = safe
); And you'll see that we define an additional aggregate, combine_numeric_avg that tells PipelineDB how to perform CREATE AGGREGATE combine_numeric_avg(internal) (
sfunc = numeric_avg_combine,
stype = internal,
finalfunc = numeric_avg,
combinefunc = numeric_avg_combine,
serialfunc = numeric_avg_serialize,
deserialfunc = numeric_avg_deserialize,
parallel = safe
); The key things to note here are:
If such a signature exists, the PipelineDB analyzer will resolve it when analyzing a We admittedly need to document this more thoroughly as it's clearly not particularly obvious. I think it would also be helpful if we added:
What do you think? |
combine
seems not work on user-define aggregate complex type.
Great! It works after I add
If there could be a Please add into the document so other one won't meet the same issue again. |
Just try to use following user-defined aggregate, on pipelinedb 1.0, pg11
with very simple stream:
view
daily
is empty because:and view
hourly
works great as expected.based on the log, it seems the combine((delta).top5) is not call COMBINEFUNC, but call SFUNC instead, then it parsed the state-object TOP_N_RESULT into TYPE_TOP_ITEM, cause the numeric "score" received a string which is the text format of array object.
it will very simple to replay the issue. Right now I just fall back to get result from original stream directly.
Add on Nov. 28
I also found another customized aggregate also fail as worker crash. which is work fine in 0.9.9.
2018-11-28 14:00:10.694 UTC [624] LOG: pipelinedb process "worker0 [prism-omni]" running with pid 624
Segmentation fault (PID 624)
PostgreSQL version: 11.0 (Debian 11.0-1.pgdg90+2)
PipelineDB version: 1.0.0 at revision b4bde99
query: daily_report_by_tenant
backtrace:
/usr/lib/postgresql/11/lib/pipelinedb.so(debug_segfault+0x33)[0x7feabf03f393]
/lib/x86_64-linux-gnu/libpthread.so.0(+0x110c0)[0x7feac726e0c0]
postgres: worker0 [prism-omni] (MakeExpandedObjectReadOnlyInternal+0x0)[0x5647c0575280]
/usr/lib/postgresql/11/lib/plpgsql.so(+0x12a52)[0x7feab4852a52]
postgres: worker0 [prism-omni] (+0x25583d)[0x5647c03df83d]
postgres: worker0 [prism-omni] (+0x27f791)[0x5647c0409791]
postgres: worker0 [prism-omni] (standard_ExecutorRun+0x163)[0x5647c03e2823]
postgres: worker0 [prism-omni] (+0x28d2eb)[0x5647c04172eb]
postgres: worker0 [prism-omni] (SPI_execute_plan_with_paramlist+0x83)[0x5647c04176f3]
/usr/lib/postgresql/11/lib/plpgsql.so(+0x1733e)[0x7feab485733e]
/usr/lib/postgresql/11/lib/plpgsql.so(+0x1956b)[0x7feab485956b]
/usr/lib/postgresql/11/lib/plpgsql.so(+0x1b92f)[0x7feab485b92f]
/usr/lib/postgresql/11/lib/plpgsql.so(plpgsql_exec_function+0x1ad)[0x7feab485baed]
/usr/lib/postgresql/11/lib/plpgsql.so(plpgsql_call_handler+0x146)[0x7feab484eca6]
postgres: worker0 [prism-omni] (+0x25536d)[0x5647c03df36d]
postgres: worker0 [prism-omni] (+0x269ba0)[0x5647c03f3ba0]
/usr/lib/postgresql/11/lib/pipelinedb.so(ExecuteContPlan+0x9b)[0x7feabf04568b]
/usr/lib/postgresql/11/lib/pipelinedb.so(ContinuousQueryWorkerMain+0x275)[0x7feabf008d95]
/usr/lib/postgresql/11/lib/pipelinedb.so(cont_bgworker_main+0x220)[0x7feabf040090]
postgres: worker0 [prism-omni] (StartBackgroundWorker+0x2ad)[0x5647c04b323d]
postgres: worker0 [prism-omni] (+0x335f55)[0x5647c04bff55]
postgres: worker0 [prism-omni] (+0x336b15)[0x5647c04c0b15]
/lib/x86_64-linux-gnu/libpthread.so.0(+0x110c0)[0x7feac726e0c0]
/lib/x86_64-linux-gnu/libc.so.6(__select+0x13)[0x7feac4f093a3]
postgres: worker0 [prism-omni] (+0xb93b3)[0x5647c02433b3]
postgres: worker0 [prism-omni] (PostmasterMain+0xe33)[0x5647c04c1ca3]
postgres: worker0 [prism-omni] (main+0x854)[0x5647c02452f4]
/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf1)[0x7feac4e482e1]
postgres: worker0 [prism-omni] (_start+0x2a)[0x5647c02453aa]
Do it probably meet the same issue?
I found the issue all happened when I do a "reduce" to one dimension. (above example is reduce the
hour
dimension).Fixed:
thanks to @derekjn , just add another new combine function with prefix
combine_
to customized aggregate will fix this issue.The text was updated successfully, but these errors were encountered: