261: /locations should return all parameters available for a station, even when filtering.#298
261: /locations should return all parameters available for a station, even when filtering.#298Jeffrey-Vervoort-KNMI wants to merge 3 commits intomainfrom
Conversation
3c6bdd8 to
d50fe06
Compare
datastore/integration-test/response/data_locations_two_points_with_five_parameters.json
Show resolved
Hide resolved
2400a3d to
3ee1811
Compare
6fed694 to
c9b0ca6
Compare
c9b0ca6 to
bff02a2
Compare
| @@ -36,21 +36,33 @@ func getLocs( | |||
|
|
|||
| // define and execute query | |||
| query := fmt.Sprintf(` | |||
There was a problem hiding this comment.
At first glance I feel that the new query is perhaps more complex than necessary. Note: this is not based on an actual understanding of what it does, only the fact that there are now redundant parts etc. Would it be possible to simplify it?
I am going to take a closer look, though. Maybe I find that this is a good solution after all.
There was a problem hiding this comment.
After spending a bit more time staring at the statement, I now think it makes better sense and is not too complex after all.
There was a problem hiding this comment.
I agree that it looks more complex. It is a trade-off between simplicity and performance.
The queries performance are the same for small databases, but when having a large number of rows in the tables, it outperforms the simpler query. Which makes it valuable for our production environment.
How it works: It uses CTE to split up the work efficiently, it applies filters early so it has a smaller set when joining.
There was a problem hiding this comment.
Sounds reasonable. But I guess my next question then is why platform is treated in a special way here? In the original issue, the problem was that you only got one parameter?
I mean, intuitively I would expect instead WITH parameter_names AS (SELECT DISTINCT ON (parameter_name) parameter_name ... and so on.
But I might be wrong.
#261