Ce n'est pas seulement "un tas de réglages (index, etc.)". C'est crucial et incontournable.
Vous avez posté quelques détails, mais essayons.
La règle est la suivante :essayez de trouver le jeu de travail le plus courant. Voir s'il tient dans la RAM. Optimisez le matériel, les paramètres de tampon PG/OS et les index/cluster PG pour celui-ci. Sinon, recherchez des agrégats, ou si ce n'est pas acceptable et que vous avez besoin d'un accès totalement aléatoire, pensez à quel matériel pourrait analyser toute la table pour vous dans un délai raisonnable.
Quelle est la taille de votre table (en gigaoctets) ? Comment se compare-t-il à la RAM totale? Quels sont vos paramètres PG, y compris shared_buffers et effective_cache_size ? Est-ce un serveur dédié ? Si vous disposez d'une table de 250 Go et d'environ 10 Go de RAM, cela signifie que vous ne pouvez tenir que 4 % de la table.
Existe-t-il des colonnes couramment utilisées pour le filtrage, telles que l'état ou la date ? Pouvez-vous identifier la plage de travail la plus couramment utilisée (comme le mois dernier uniquement) ? Si tel est le cas, envisagez de partitionner ou de regrouper ces colonnes et de les indexer définitivement. Fondamentalement, vous essayez de vous assurer que la plus grande partie possible de l'ensemble de travail tient dans la RAM.
Évitez à tout prix de scanner la table si elle ne rentre pas dans la RAM. Si vous avez vraiment besoin d'un accès absolument aléatoire, la seule façon de l'utiliser est un matériel vraiment sophistiqué. Vous auriez besoin d'une configuration de stockage/RAM persistante capable de lire 250 Go en un temps raisonnable.
