Forums PostgreSQL.fr

simon

Membre

Optimisation

hi,

Someone can help me to  see different file using by PostgreSQL  for manage table partitioned.
Thank.

Dernière modification par simon (07/12/2017 18:58:23)

rjuju

Administrateur

Re : Optimisation

Hi,

This is a french speaking community.  Also, your question isnn't clear, what's exactly your issue?

---

Julien.
https://rjuju.github.io/

simon

Membre

Re : Optimisation

ok très bien, en fait je veux comprendre comment PostgreSQL estime le coût des requêtes sur une table partitionnée.

rjuju

Administrateur

Re : Optimisation

À moins que vous ayez une question plus précise, la seule réponse que j'ai est qu'il fait la somme des coûts d'accès aux différentes partitions.

---

Julien.
https://rjuju.github.io/

simon

Membre

Re : Optimisation

Ok, par exemple:
si j'ai R(a,b,c) que je fasse un partitionnement horizontal par range sur les valeurs de b; R1(a,b,c) R2(a,b,c) . Supposons que je fasse une requête dont la clause where fait référence aux valeurs dans R1 en exemple select * from r where b=...; Comment postgres va réagir pour le calcul du coût car a ma compréhension il fera le calcul de coût de parcours de R1 puis R(bien qu'il est vide)  puis la fusion des deux en tout on aura: c=cR1+cR+cFusion. Si ma réflexion est juste, je ne comprends pas prk cFusion car cR est vide. Merci

rjuju

Administrateur

Re : Optimisation

Je vais supposer que vous parlez du partitionnement déclaratif ajouté dans la version 10.  Les tables qui sont partitionnées ne peuvent pas contenir de données, postgres n'essaiera donc pas de les parcourir.  Si l'exécuteur est capable de déterminer la partition au moment de la planification (pas de requête préparée avec paramètre sur la ou les colonnes participant au partitionnement donc), il excluera toutes les partitions inutiles.

Par exemple :

rjuju=# \d+ simple
                                   Table "public.simple"
 Column |  Type   | Collation | Nullable | Default | Storage  | Stats target | Description 
--------+---------+-----------+----------+---------+----------+--------------+-------------
 id     | integer |           |          |         | plain    |              | 
 val    | text    |           |          |         | extended |              | 
Partition key: RANGE (id)
Partitions: simple_0_1 FOR VALUES FROM ('-100000') TO (1),
            simple_1_2 FOR VALUES FROM (1) TO (100000),
            simple_2_3 FOR VALUES FROM (100000) TO (200000)

rjuju=# explain select * from simple where id = 1;
                                        QUERY PLAN                                         
-------------------------------------------------------------------------------------------
 Append  (cost=0.29..8.31 rows=1 width=14)
   ->  Index Scan using simple_1_2_id_idx on simple_1_2  (cost=0.29..8.31 rows=1 width=14)
         Index Cond: (id = 1)
(3 rows)

rjuju=# explain select * from simple_1_2 where id = 1;
                                     QUERY PLAN                                      
-------------------------------------------------------------------------------------
 Index Scan using simple_1_2_id_idx on simple_1_2  (cost=0.29..8.31 rows=1 width=14)
   Index Cond: (id = 1)
(2 rows)

Le coût estimé est donc exactement le même que si on utilise directement la bonne partition.

---

Julien.
https://rjuju.github.io/

gleu

Administrateur

Re : Optimisation

Et si ce n'est pas la version 10, il vérifie la table partitionnée parce qu'il n'a pas la certitude qu'il n'y a rien.

---

Guillaume.

simon

Membre

Re : Optimisation

Ok, peut c'est la version car je travaille avec 9.4.5.