Paramètres de coût du planificateur
Cela me dit que votre random_page_cost et seq_page_cost ont probablement tort. Vous utilisez probablement un stockage avec des E/S aléatoires rapides, soit parce que la majeure partie de la base de données est mise en cache dans la RAM, soit parce que vous utilisez un SSD, un SAN avec cache ou un autre stockage où les E/S aléatoires sont intrinsèquement rapides.
Essayez :
SET random_page_cost = 1;
SET seq_page_cost = 1.1;
pour réduire considérablement les différences de paramètres de coût, puis réexécutez. Si cela fonctionne, envisagez de modifier ces paramètres dans postgresql.conf. .
Vos estimations du nombre de lignes sont raisonnables, donc cela ne ressemble pas à un problème d'erreur d'estimation du planificateur ou à un problème avec de mauvaises statistiques de table.
Requête incorrecte
Votre requête est également incorrecte. OFFSET 0 LIMIT 1 sans ORDER BY produira des résultats imprévisibles à moins que vous ne soyez assuré d'avoir exactement une correspondance, auquel cas le OFFSET ... LIMIT ... les clauses sont inutiles et peuvent être entièrement supprimées.
Il est généralement préférable de formuler des requêtes telles que SELECT max(...) ou SELECT min(...) lorsque c'est possible; PostgreSQL aura tendance à être en mesure d'utiliser un index pour simplement extraire la valeur souhaitée sans effectuer une analyse de table coûteuse ou une analyse et un tri d'index.
Conseils
BTW, pour les questions futures, le wiki PostgreSQL contient de bonnes informations dans la catégorie de performance et un guide pour poser des questions de requête lente .
