perf(sql): speed up GetForecastAtTimestamp via DISTINCT

[peterdudfield]

Contribution Checklist

• Have you followed the Open Climate Fix Contribution Guidelines?
• Have you referenced the Issue this PR addresses, where applicable?
• Have you checked to ensure there aren't other open Pull Requests for the same change?
• Have you added a summary of the changes?
• Have you written new tests for your changes, where applicable?
• Have you successfully run make lint with your changes locally?
• Have you successfully run make test with your changes locally?

Warning

PRs may be closed if all the above boxes are not checked.

Changes in this Pull Request

Reduces the amount of forecasts that are collected in the ForecastAtTimestamp query

[github-actions]

Benchmark Results

Benchmark results

?   	github.com/openclimatefix/data-platform/cmd	[no test files]
?   	github.com/openclimatefix/data-platform/internal/gen/ocf/dp	[no test files]
?   	github.com/openclimatefix/data-platform/internal/interceptors	[no test files]
PASS
ok  	github.com/openclimatefix/data-platform/internal/server/dummy	0.004s
{"level":"debug","time":"2026-01-07T14:32:18Z","message":"Running migrations"}
goos: linux
goarch: amd64
pkg: github.com/openclimatefix/data-platform/internal/server/postgres
cpu: AMD EPYC 7763 64-Core Processor                
BenchmarkPostgresClient/6144000/GetForecastAsTimeseries-4         	     165	   6811577 ns/op
BenchmarkPostgresClient/6144000/GetForecastAtTimestamp-4          	     162	   7243111 ns/op
BenchmarkPostgresClient/6144000/GetObservationsAsTimeseries-4     	     938	   1231489 ns/op
BenchmarkPostgresClient/6144000/CreateForecast-4                  	     273	   4085155 ns/op
PASS
ok  	github.com/openclimatefix/data-platform/internal/server/postgres	187.156s
?   	github.com/openclimatefix/data-platform/internal/server/postgres/gen	[no test files]

Benchmark vs base branch

goos: linux
goarch: amd64
pkg: github.com/openclimatefix/data-platform/internal/server/postgres
cpu: AMD EPYC 7763 64-Core Processor                
                                                     │ bench-main.txt │ bench-speed-up-forecast-at-timestamp.txt │
                                                     │     sec/op     │     sec/op       vs base                 │
PostgresClient/6144000/GetForecastAsTimeseries-4         4.826m ± ∞ ¹      6.812m ± ∞ ¹        ~ (p=1.000 n=1) ²
PostgresClient/6144000/GetForecastAtTimestamp-4        105.004m ± ∞ ¹      7.243m ± ∞ ¹        ~ (p=1.000 n=1) ²
PostgresClient/6144000/GetObservationsAsTimeseries-4     1.307m ± ∞ ¹      1.231m ± ∞ ¹        ~ (p=1.000 n=1) ²
PostgresClient/6144000/CreateForecast-4                  2.612m ± ∞ ¹      4.085m ± ∞ ¹        ~ (p=1.000 n=1) ²
geomean                                                  6.449m            3.969m        -38.45%
¹ need >= 6 samples for confidence interval at level 0.95
² need >= 4 samples to detect a difference at alpha level 0.05

[peterdudfield]

Althought benchmark is not working, previous PR have

PostgresClient/6144000/GetForecastAtTimestamp-4         105.00m ± ∞ ¹   23.67m ± ∞ ¹   

So its gone down form 23.67m to 7.5m

[peterdudfield]

I wante to just do LIMIT length(sqlc.arg(geometry_uuids)::UUID []), but it didnt seem to work

[devsjc]

I'm not sure this LIMIT does anything other than doing an uneccessary count procedure - you're already getting DISTINCT on the geometry_uuid and filtering to asked-for geometry UUIDs in the WHERE clause. Is there any noticable difference in the speed if you remove it?

[peterdudfield]

ah, let me check

[peterdudfield]

no noticiable limit, so Ill remove this

[devsjc]

Althought benchmark is not working, previous PR have

PostgresClient/6144000/GetForecastAtTimestamp-4         105.00m ± ∞ ¹   23.67m ± ∞ ¹   

So its gone down form 23.67m to 7.5m

Worth noting that there's a bug in the main benchmark - it hasn't updated for a while. The current speed of the GetForecastAtTimestamp is more like ~20ms. I need to look into this!