Timescaledb: Support for PG11

Created on 17 Aug 2018 · 15Comments · Source: timescale/timescaledb

I didn't see an existing issue for this yet, so I thought I'd create one. Postgres 11 is now in Beta 3, which I think makes it a good time to start supporting it in TimescaleDb. We'd like to start testing the beta of PG11 for bugs/incompatibilities, but currently can't properly test it without TimescaleDb support for it.

enhancement

Source

fvannee

👍8

Most helpful comment

Yep! It's close should be a PR coming in the next few days, just working out a few kinks in handling upserts and updating a few tests.

davidkohn88 on 27 Nov 2018

👍10 🎉4

All 15 comments

Hi @fvannee thanks for creating an issue. This is on our nearer-term roadmap, just have a few other things that we are prioritizing for the next releases.

mfreed on 19 Aug 2018

Any rough idea what is required to become compatible with PG11? Is it just a matter of including some different headers and renaming some symbols or are there deeper levels of incompatibility?

fvannee on 19 Aug 2018

We haven't really looked into this in any detail. I can say, however, that with PG10 it was mostly about just going through and updating different headers/symbols, etc. as you point out. I expect it to be more like this for PG11 as well, but that's just the intuition.

mfreed on 29 Aug 2018

+1 for PG11. I'm also eager to prepare a release of OpenBMP using PG11 + TimescaleDB 1.0.0.

TimEvens on 10 Oct 2018

+100
Are you working on it?

I'm evaluating replacing some internal in house tools with pg, but it'd be PG11 and I'd like to compare timescaleDB with plain PG11, our needs are basic and PG tables partitioning would be good enough.

For our own internal use I mostly did it. It compiles but saying there's some rough edges is an understatement.

did-g on 12 Oct 2018

@mfreed While PostgreSQL 11 support could be a more-or-less straight port it is worth to consider the declarative partition functionality, as it is greatly expanded - see https://www.postgresql.org/about/featurematrix/#partitioning-inheritance - and, with the on-going work for PostgreSQL 12 on partition performance, trigger / inheritance based solutions will become rarer in production deployments IMHO.

jesperpedersen on 19 Oct 2018

Exactly, with PG11 released now and already containing some good improvements on run-time pruning for partitions (only Append node unfortunately though), I expect many of this to be perfected in PG12 (some great partitioning performance improvement patches are open in the commitfest at the moment).
I think it would be possible to switch TimescaleDb to use declarative partioning as implementation rather than inheritance-based solution (especially now that hash partitioning and subpartitioning is also supported), but it would require quite a bit of implementation effort I think. Still I think it will be worth it given the expected performance benefits.

fvannee on 19 Oct 2018