Open Pierre-Alexandre35 opened 11 months ago
Hi,
Looks like you might be hitting the JIT performance regression issue here which is a more general PG problem with partitioned tables. We have an outstanding issue about investigating if we can do something about this problem.
In the meantime, disabling JIT for these types of queries should help here. You can do that by disabling it for the role you are using to connect like this:
alter role mytestrole set jit=off;
Note: you will have to reconnect for this to take affect.
Let me know if this helps with the performance.
I haven't got anything to add about the JIT comment, but the slow-runing query presented could be tackled with an AsOf Join. This is currently the most voted TimescaleDB feature request (see #271) but for now you could use a generated timeseries and a lateral join which would speed up the specfic query example given. Something similar to...
SELECT cond.*
from (select * from generate_series('2022-01-01 00:00:00'::timestamptz, '2022-12-31 00:00:00'::timestamptz, '1 day'::interval)) as gs(x)
cross join lateral
(select * from conditions
where conditions.time >= gs.x
order by conditions.time asc limit 1) as cond;
I tested on a one second sensor table (30M rows per year) that I have and got a 70s run time on the originl query versus 100ms run time for the lateral join method.
What type of bug is this?
Performance issue
What subsystems and features are affected?
Query executor
What happened?
Hello,
I have a table
conditions
with 10.5 millions rows. Those lines are coming from an IoT device that create data every 3 seconds (so 1 year is around 10.5M lines).I am running a simple query to
SELECT *
and the performance seems decent (around 1 second). However, when it comes to only select a definite sample (1 row per day --> 365 rows), it's taking more than 30 seconds. Not quite sure if this should be the normal behaviour in term of performance. This is the script used to create my schema:I have some performance issues to retrieve my data for more "complex" queries:
simple SELECT:
query:
result:
More complex SELECT:
query (only display 1 row per day - since
result:
I have also tried this with a little improvement but still around 25 seconds:
TimescaleDB version affected
2.5
PostgreSQL version used
14
What operating system did you use?
Apple M2 Pro
What installation method did you use?
Docker
What platform did you run on?
On prem/Self-hosted
Relevant log output and stack trace
No response
How can we reproduce the bug?