Vous n'êtes pas identifié(e).
Pages : 1
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)
Hors ligne
Hi,
This is a french speaking community. Also, your question isnn't clear, what's exactly your issue?
Julien.
https://rjuju.github.io/
Hors ligne
ok très bien, en fait je veux comprendre comment PostgreSQL estime le coût des requêtes sur une table partitionnée.
Hors ligne
À 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/
Hors ligne
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
Hors ligne
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/
Hors ligne
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.
Hors ligne
Ok, peut c'est la version car je travaille avec 9.4.5.
Hors ligne
Pages : 1