Vous n'êtes pas identifié(e).
- Contributions : Récentes | Sans réponse
Pages : 1
#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 )
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.
Pages : 1