Le problème que nous rencontrons est que lors de requêtes faites sur des polygones contenant trop de bâtiments (ex : Nante ou Lyon) le QueryPlanner de postgresql préfère utiliser l'index contenant les id des bâtiments plutôt que celui contenant les shapes des bâtiments. Le problème est bien décrit dans cet article.
Pour empêcher la base d'utiliser l'index des id, nous trions les requêtes en utilisant la colonne created_at lorsqu'une requête contient un filtre géographique (filtres bb et insee_code). La modification de la colonne de tri à la volée n'est pas possible en utilisant la CursorPagination fournie par DRF, nous créons notre propre classe de pagination.
Important : pour fonctionner, ce correctif doit s'accompagner de la modification de valeurs de configuration de la base de données :
set seq_page_cost = 1;
set random_page_cost = 1.1;
Nous nous sommes basés sur la doc de postgres pour aboutir à ces valeurs.
Suite à une remarque de Nantes sur l'impossibilité de récupérer les bâtiments de la ville (timeout sur https://rnb-api.beta.gouv.fr/api/alpha/buildings/?insee_code=44109) on modifie le mécanisme de pagination qui cause les ralentissements.
Le problème que nous rencontrons est que lors de requêtes faites sur des polygones contenant trop de bâtiments (ex : Nante ou Lyon) le QueryPlanner de postgresql préfère utiliser l'index contenant les id des bâtiments plutôt que celui contenant les shapes des bâtiments. Le problème est bien décrit dans cet article.
Pour empêcher la base d'utiliser l'index des id, nous trions les requêtes en utilisant la colonne
created_atlorsqu'une requête contient un filtre géographique (filtresbbetinsee_code). La modification de la colonne de tri à la volée n'est pas possible en utilisant laCursorPaginationfournie par DRF, nous créons notre propre classe de pagination.Important : pour fonctionner, ce correctif doit s'accompagner de la modification de valeurs de configuration de la base de données :
Nous nous sommes basés sur la doc de postgres pour aboutir à ces valeurs.