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
Jeffrey-Vervoort-KNMI
force-pushed
the
261-locations
branch
from
3c6bdd8 to
d50fe06
Compare
|
datastore/integration-test/response/data_locations_two_points_with_five_parameters.json
Show resolved
Hide resolved
Jeffrey-Vervoort-KNMI
force-pushed
the
261-locations
branch
4 times, most recently
from
2400a3d to
3ee1811
Compare
Jeffrey-Vervoort-KNMI
force-pushed
the
261-locations
branch
from
6fed694 to
c9b0ca6
Compare
Jeffrey-Vervoort-KNMI
force-pushed
the
261-locations
branch
from
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.
There was a problem hiding this comment.
I will try to explain it based on my understanding. I think because the Postgres query planner does most of the work already. When I put other parts in the with statements, I did not saw any changes in performance or execution order. So I think it already picked the best path for the execution of parameter_names. At least when I made variations on Lukas his query and compared them. But for platform it did make a difference, the execution order changed after putting it in a CTE, and the query became more efficient when having a large number of rows.
3 participants
#261