Postgres: 'NO_TS_TUNE' Var
I've migrated an existing service without any problems to the new database plugin (postgres). During migration a var called 'NO_TS_TUNE' (value 'true') was added automatically. When creating a new project from scratch and adding a database via plugin (once again postgres) this var isn't added by default. I'm wondering now a) what this var is doing and b) what the best practice is when hosting on railway.
In regard of a) I've found the following (but this is related to timescaledb so I'm not sure if this is really correct here..) https://github.com/timescale/timescaledb-docker#notes-on-timescaledb-tune . From this text I assume I should always set 'NO_TS_TUNE' to true on railway ?
GitHub
GitHub - timescale/timescaledb-docker: Release Docker builds of Tim...
Release Docker builds of TimescaleDB. Contribute to timescale/timescaledb-docker development by creating an account on GitHub.
Solution:Jump to solution
a legacy postgres database is postgres 13 with timescale and postgis extensions installed.
the migration process deploys a postgres 15 database with timescale and postgis extensions as a safe bet to try to stay relatively true to the legacy databases in case anyone's code is using either of those extensions, that no ts tune is just a recommended variable to set, and since variables aren't hidden away under the mask of a plugin you get to see that variable.
if you went and deployed a postgres database manually it would deploy a regular postgres 16 database because at that point it's up to the user to decide if they need timescale or postgis extensions, that variable isn't applicable for databases without the timescale extension...
8 Replies
Project ID:
9bc5eee0-2732-4f79-af72-ba82871f6bd7Migrated Project-ID : 9bc5eee0-2732-4f79-af72-ba82871f6bd7
Project created from Scratch ID: 40abdc58-69e9-4ac6-8ad0-dc5114563876
Oh and I can see what the 'NO_TS_TUNE' var is doing. When it isn't present (or set to false) there seems to be a "recycle" task running on the postgres database each 10 minutes:
'2024-01-20 11:56:25.796 UTC [29] LOG: checkpoint complete: wrote 7 buffers (0.0%); 0 WAL file(s) added, 0 removed, 0 recycled; write=0.603 s, sync=0.003 s, total=0.612 s; sync files=5, longest=0.002 s, average=0.001 s; distance=20 kB, estimate=614 kB; lsn=0/1AAF1C8, redo lsn=0/1AAF190'
Are there any performance issues realted to this or because of what railway adds this var automatically during a migration ? I would assume without this var you can perhaps save a bit of resources ?
NO_TS_TUNE is for PostgreSQL timescale.
To not run timescaledb-tune at all, use the NO_TS_TUNE environment variable:
GitHub
GitHub - timescale/timescaledb-docker: Release Docker builds of Tim...
Release Docker builds of TimescaleDB. Contribute to timescale/timescaledb-docker development by creating an account on GitHub.
Solution
a legacy postgres database is postgres 13 with timescale and postgis extensions installed.
the migration process deploys a postgres 15 database with timescale and postgis extensions as a safe bet to try to stay relatively true to the legacy databases in case anyone's code is using either of those extensions, that no ts tune is just a recommended variable to set, and since variables aren't hidden away under the mask of a plugin you get to see that variable.
if you went and deployed a postgres database manually it would deploy a regular postgres 16 database because at that point it's up to the user to decide if they need timescale or postgis extensions, that variable isn't applicable for databases without the timescale extension
Thx @Brody
Do you by any change know why I can't mark your answer as the solution ? 😄
i had to disable that because too many users where marking the wrong message as an answer, but i can't disable the message that tells you to mark a message as an answer