>I also tried cstore_fdw for this, but my queries
>(building a 2-D histogram) were taking 4+ seconds,
>compared to 500ms using arrays.
> ...
> but maybe I could write my own extension
"TimescaleDB is an open-source database designed to make SQL scalable for time-series data.
>(building a 2-D histogram) were taking 4+ seconds,
>compared to 500ms using arrays.
> ...
> but maybe I could write my own extension
Have you checked the new TimescaleDB extension? [ https://github.com/timescale/timescaledb ]
"TimescaleDB is packaged as a PostgreSQL extension and released under the Apache 2 open-source license."
"TimescaleDB is packaged as a PostgreSQL extension and released under the Apache 2 open-source license."
"TimescaleDB is an open-source database designed to make SQL scalable for time-series data.
It is engineered up from PostgreSQL, providing automatic partitioning across time and space (partitioning key), as well as full SQL support."
and it has a built in histogram function: https://docs.timescale.com/latest/api/api-timescaledb#histogram
Regards,
Imre
2017-09-21 23:05 GMT+02:00 Paul A Jungwirth <pj@xxxxxxxxxxxxxxxxxxxxxxxx>:
> It's going to suck big-time :-(.
Ha ha that's what I thought, but thank you for confirming. :-)
> We ended up keeping
> the time series data outside the DB; I doubt the conclusion would be
> different today.
Interesting. That seems a little radical to me, but I'll consider it
more seriously now. I also tried cstore_fdw for this, but my queries
(building a 2-D histogram) were taking 4+ seconds, compared to 500ms
using arrays. Putting everything into regular files gives up filtering
and other SQL built-ins, but maybe I could write my own extension to
load regular files into Postgres arrays, sort of getting the best of
both worlds.
Anyway, thanks for sharing your experience!
Yours,
Paul
--
Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
