[gull] Parallelize Postgresql request

[Yves Martin]

On Thu, 2024-10-10 at 08:39 +0200, felix via gull wrote:
> Voilà un sujet surprenant.
> 
> Un client me contacte car il à créé une base de données PostgreSQL,
> sous window, avec une machine performante. Son projet fonctionne,
> il décide de le passer sur machine tournant sous Linux.
> 
> Là il constate qu'un requête `select count(*) from SomeView where
> Id=12;`
> prend environ 28 secondes sous Linux alors que sous Window, la
> réponse
> arrive en 8 secondes!
> 
> Les machines sont différentes, mais cela n'explique pas:
>    - Window 32G 12 coeurs 3GHz
>    - Linux  16G 8 coeurs. 3.2GHz
> Sous linux la swap n'est pas accédée.
> 
> En donc en suivant les acticités des processeurs, sous window on voit
> clairement les 12 cpu qui s'agittent durant les 8 secondes, alors que
> sous linux, on voit 1 processeur au top durant 4 secondes, puis un
> autre 
> ``prend le relais'', ainsi de suite, à aucun moment je ne voit plus
> d'un 
> coeur au top. A noter que sous window, les 12 courbes s'agittent mais
> aucune ne top (cela me semble logique en réfléchissant à la
> complexité
> d'un requête de VUE qui contient des JOIN et autre resultat à
> imbriquer).
> 
> J'ai cherché les options de parallelization dans les configs de
> postgresql,
> sur google&co, je dois dire que je ne vois pas...
> Je n'ai pas bien compris non plus les calculs de coûts:
> 
> #seq_page_cost = 1.0                    # measured on an arbitrary
> scale
> #random_page_cost = 4.0                 # same scale as above
> #cpu_tuple_cost = 0.01                  # same scale as above
> #parallel_tuple_cost = 0.1              # same scale as above
> #parallel_setup_cost = 1000.0           # same scale as above
> ...
> 
> Il faut dire que ``measured on an arbitrary scale'' et ``same scale
> as above''
> ne sont pas des information très explicites.

Bonjour,

Ce qui est surprenant c'est déjà le temps d'exécution quelque soit le
systême:
 - Que fait donc la "SomeView" comme calcul ou accès pour que cela
prenne autant de temps ?
 - Est-ce vraiment le CPU qui est limitant ?
 - Ne manquerait-il pas tout simplement des index sur les critères de
filtrage, en supposant qu'ils sont présents sur les foreign key
utilisés pour les jointures ?

Pour optimiser, je recommande l'usage de:
- pg_stat_statements
- pgBadger

afin d'identifier si le temps de réponse correspond à des accès disque
ou des calculs "bruts" (formules ou procédures stockées) ou à des
parcours d'index

Je pose aussi un pari sur une valeur de work_mem trop faible qui limite
les traitements de jointure et de tri.

En espérant que ça puisse aider
-- 
Yves Martin