New timescale sink

[binarylogic]

I'd like to support Timescale as a sink, and after talking to them it appears we just need to support Postgres since Timescale is built on Postgres. I'm hesitant to call it a Postgres sink given that we'll probably want to make certain assumptions about how we're writing data. Before we begin work we should determine if this is the appropriate course of action.

Ref #935

[ghost]

I’m not familiar with Timescale, but wonder would it make sense support unified SQL sinks, which would include Postgres, ClickHouse, and at least for the sake of easy tests, SQLite. The idea is to have same configuration structure for them and, ideally, support some kind of automatic table creation/migrations.

[jamessewell]

As far as writing data there is no difference between Timescale and Postgres.

It would be up to the user to configure the destination tables (and hypertables in the Timscaledb case) before the sink was used.

[akulkarni]

A general unified SQL sink might be challenging given the language variants between the different databases.

But @jamessewell is correct, there should be no difference in writing data between Timescale and Postgres (but there may be other reasons for creating a Timescale specific sink).

[jamessewell]

I forgot to note our progress here: this can be achieved using PostgREST (a REST gateway for PostgreSQL) . Performance is very good.

[123BLiN]

@jamessewell Could you please elaborate on details of your implementation of this if possible?
Are you using http sink to drop events to PostgREST? And how do you create some tables in timescaledb before starting to push events?

[ypid-geberit]

Note that there is a more generic issue #6556 which should probably be implemented first. As discussed above, it might even already solve this issue.

[jszwedko]

Repurposing this to be for timescale specifically. #15765 is tracking a generic postgres sink.