Vous n'êtes pas identifié(e).

#1 Re : Publications » Nouvel article : Migration Oracle ou SQL Server vers PosteGreSQL - les » 12/10/2011 13:44:15

La seule conclusion à tirer de ce glorieux échange, c'est que tu mérite bien le surnom SQLTroll.

#2 Re : Publications » Nouvel article : Migration Oracle ou SQL Server vers PosteGreSQL - les » 12/10/2011 09:18:24

Je me permet de répondre à quelques points.

1 - Aucune gestion des espaces de stockage.
Faux toi pas savoir lire doc.

3 - Un partitionnement plus que léger
Vrai.

8 - Une administration couteuse
On doit passer 100 fois plus de temps sur notre oracle que sur nos pgsql/mysql.

9 - pas de pooling des connexions
Le listener d'oracle qui fait office de pooleur est bien un processus indépendant, conceptuellement c'est la même chose que pg/mysql

11 - Un processus de sauvegarde peu performant
Sauvegarder table par table est un besoin "particulier" qui ne concerne que les élèves de Papouasie de nouvelle guinée.

12 - Pas de compression ni de cryptage des données
Table toast compresser par défaut.

13 - Pas de réplication des données
HAHAHAHAHAHAHAHAHAHAHA ! Encore oublier de lire la doc on dirais.

15 - En conclusion
Plutôt que de l'ignorer le renommer en SQLTroll serait plus pertinent.

#3 Re : Publications » Nouvel article : Migration Oracle ou SQL Server vers PosteGreSQL - les » 12/10/2011 08:59:25

*popcorn*

ps: Ce post est un peu près du même niveau que notre cher professeur.

#4 Re : Optimisation » Problème de contraintes sur une table partitionnée. » 22/04/2010 16:00:45

Voila qui explique tout, je pensais naïvement que Pg vérifiait les contraintes "à la volée".

(enfin du coup ça m'arrange pas tongue )

Merci.

#5 Optimisation » Problème de contraintes sur une table partitionnée. » 22/04/2010 12:00:10

PatrickB
Réponses : 2

J'ai décelé un problème sur une de nos bases postgresql (8.2.4)

La table documents est partitionnée par identifiant de sources :
- On a parfois plusieurs sources par tables filles.
- La dernière table fille a une contrainte du type : "le doc n'est pas la source x" (table par défaut pour les nouvelles sources).
- Quelques indexes sont différents, à cause de la nature de certaines sources, mais ça ne devrait pas influer sur les tables filles à interroger.

# SHOW constraint_exclusion ;
constraint_exclusion | on

Lorsqu'on test directement avec l'identifiant de la source aucun problème, il interroge directement la bonne table fille.

#explain analyse SELECT id_source,count(*) from documents where documents.id_source in (577) and dav='today' group by id_source order by id_source;
                                                                             QUERY PLAN                                                                             
--------------------------------------------------------------------------------------------------------------------------------------------------------------------
GroupAggregate  (cost=7428.65..7430.19 rows=77 width=2) (actual time=29.903..29.904 rows=1 loops=1)
   ->  Sort  (cost=7428.65..7428.84 rows=77 width=2) (actual time=29.695..29.785 rows=152 loops=1)
         Sort Key: public.documents.id_source
         ->  Append  (cost=0.00..7426.23 rows=77 width=2) (actual time=4.462..29.500 rows=152 loops=1)
               ->  Seq Scan on documents  (cost=0.00..19.60 rows=1 width=2) (actual time=0.002..0.002 rows=0 loops=1)
                     Filter: ((id_source = 577) AND (dav = '2010-04-22'::date))
               ->  Index Scan using idx_documents_z_dav on documents_z documents  (cost=0.00..7406.63 rows=76 width=2) (actual time=4.458..29.345 rows=152 loops=1)
                     Index Cond: (dav = '2010-04-22'::date)
                     Filter: (id_source = 577)
Total runtime: 30.021 ms


Par contre si j'utilise une requête avec une jointure pg interroge toute les tables filles.
(il se comporte exactement de la même façon avec constraint_exclusion a 'off')

# explain analyse select name,count(*) from documents,sources where documents.id_source=sources.id and sources.name in ('toto') and dav='today' group by name order by name;
                                                                                 QUERY PLAN                                                                                 
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------
GroupAggregate  (cost=0.00..31667.07 rows=1 width=7) (actual time=117.708..117.708 rows=1 loops=1)
   ->  Nested Loop  (cost=0.00..31666.79 rows=54 width=7) (actual time=78.417..117.312 rows=582 loops=1)
         Join Filter: (public.documents.id_source = sources.id)
         ->  Index Scan using idx_sources_name on sources  (cost=0.00..8.27 rows=1 width=11) (actual time=0.112..0.115 rows=1 loops=1)
               Index Cond: (name = 'toto'::text)
         ->  Append  (cost=0.00..31157.13 rows=40111 width=2) (actual time=0.321..94.204 rows=39178 loops=1)
               ->  Seq Scan on documents  (cost=0.00..18.00 rows=3 width=2) (actual time=0.001..0.001 rows=0 loops=1)
                     Filter: (dav = '2010-04-22'::date)
               ->  Index Scan using idx_documents_a_id_source_dav on documents_a documents  (cost=0.00..3665.17 rows=2063 width=2) (actual time=0.085..0.085 rows=0 loops=1)
                     Index Cond: ((public.documents.id_source = sources.id) AND (public.documents.dav = '2010-04-22'::date))
               ->  Index Scan using idx_documents_b_id_source_dav on documents_b documents  (cost=0.00..4290.27 rows=2417 width=2) (actual time=0.051..0.051 rows=0 loops=1)
                     Index Cond: ((public.documents.id_source = sources.id) AND (public.documents.dav = '2010-04-22'::date))
               ....
               ->  Bitmap Heap Scan on documents_z documents  (cost=2205.26..2257.24 rows=13 width=2) (actual time=5.899..5.899 rows=0 loops=1)
                     Recheck Cond: ((public.documents.dav = '2010-04-22'::date) AND (public.documents.id_source = sources.id))
                     ->  BitmapAnd  (cost=2205.26..2205.26 rows=13 width=0) (actual time=5.895..5.895 rows=0 loops=1)
                           ->  Bitmap Index Scan on idx_documents_z_dav  (cost=0.00..197.71 rows=8490 width=0) (actual time=5.582..5.582 rows=26675 loops=1)
                                 Index Cond: (dav = '2010-04-22'::date)
                           ->  Bitmap Index Scan on idx_documents_z_id_source_nod  (cost=0.00..2005.17 rows=60124 width=0) (actual time=0.059..0.059 rows=0 loops=1)
                                 Index Cond: (public.documents.id_source = sources.id)
Total runtime: 117.993 ms

Visiblement des qu'il y a une jointure avec la table source pgsql decide de shunter les contraintes.
Il se comporte de la même manière en utilisant une sous-requête.

En production, on passe d'un cout de 968000 à 11000.

Pied de page des forums

Propulsé par FluxBB