Re: Parallelize Postgresql request
Marc SCHAEFER via gull <gull-04vmY7CpswVinyhjFObuvR+/[email protected]> Sat, 12 Oct 2024 21:46:40 +0200
| Newsgroups | gmane.org.user-groups.gull.general |
|---|---|
| Message-ID | <[email protected]> |
Bonjour, On Fri, Oct 11, 2024 at 08:51:26AM +0200, Marc SCHAEFER via gull wrote: > Si jamais tu arrivais à faire une requête, par exemple sur les > tables internes de PostgreSQL -- ou en nous fournissant les données > et les requêtes -- qui montre le problème, on pourrait tester > sur nos installations :) J'ai posé une question à la liste postgresql-general: > template1=> SELECT COUNT(*) FROM pg_class a, pg_class b, pg_class c; Une requête un peu stupide mais qui montre bien 1 seul CPU actif. La réponse: If you set set min_parallel_table_scan_size = 0 then it uses parallelism, and completes much faster. The planner generally works by comparing the estimated cost of various plans (it is a "cost based" optimiser), but the decision to actually consider parallelism at all is essentially "rule based", and the rules aren't smart enough for this query with default settings. pg_class is considered too small to bother parallelising the scan, and here you have a 3-way cross-join which generates an enormous of work for each tuple so it is actually a good idea to parallelise it. I guess people don't actually do that too often. Donc c'est bien en direction de l'optimiseur qu'il faut probablement regarder, tout en étant conscient que l'exemple ci-dessus est tiré par les cheveux. _______________________________________________ gull mailing list [email protected] https://forum.linux-gull.ch/mailman/listinfo/gull