Timeline for Speeding up GeoServer response - splitting the main PostgreSQL table into multiple sub tables instead of using views would help?
Current License: CC BY-SA 4.0
7 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Sep 10, 2020 at 9:05 | comment | added | umbe1987 | That clarifies my doubts. Thank you for your time and patience ;) | |
| Sep 10, 2020 at 9:04 | comment | added | Ian Turton | indexes are a postgresql/postigis issue - you should certainly have a spatial index and then an index on any attribute you query regularly | |
| Sep 10, 2020 at 8:59 | comment | added | umbe1987 | this link and your answer really helped me: spin.atomicobject.com/2018/04/09/postgres-materialized-views | |
| Sep 10, 2020 at 8:56 | vote | accept | umbe1987 | ||
| Sep 10, 2020 at 8:56 | comment | added | umbe1987 | Regarding the index, if you know, are you talking about PostgreSQL indexes, PostGIS spatial indexes, or something related to GeoServer? (sorry but I have to investigate on this, I see there are indexes in my main attribute and geographic tables, but none in the views for instance, which i am about to add now) | |
| Sep 10, 2020 at 8:49 | comment | added | umbe1987 | Hi Ian, thanks for the great answer. Unfortunately 1 and 2 are out of choice as 1. these layers should be visible from all scales, and for 2. historical data might change now because we are in the phase where we are testing different algorithm to produce the data. Can you tell me a bit about the index? I think I might have indexes, but I am not sure how I should check. Anyway, I found out that MATERIALIZED VIEWS are a great way to improve performance, as they actually are more as db tables than db views and as such they retain less rows and are faster to query. | |
| Sep 10, 2020 at 8:38 | history | answered | Ian Turton | CC BY-SA 4.0 |