From: | Cousin Florence <fcousin(at)sopragroup(dot)com> |
---|---|
To: | Pierre Y(dot) <pierre(dot)y(at)gmail(dot)com>, "pgsql-fr-generale(at)postgresql(dot)org" <pgsql-fr-generale(at)postgresql(dot)org> |
Subject: | RE : Performances fetchs 3.5M lignes |
Date: | 2012-01-20 13:40:08 |
Message-ID: | 26185_1327066809_4F196EB9_26185_5903_1_04342584A50D464A8AC25977C391BE6F15CA4F@wancyexmbx03.ancy.fr.sopra |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-fr-generale |
Pour le plan d'exécution lui-même, je ne vois rien de surprenant étant donné que la requête ramène TOUTES les lignes de la jointure (probablement toutes les lignes de user_parutions donc). Je ne vois pas comment cela pourrait être plus rapide avec l'utilisation d'index qu'avec un hash join. L'utilisation d'index serait manifestement plus lente dans ce cas, il me semble.
(Si vous voulez mieux comprendre, cherchez sur le Net : "faroult stephane youtube joins", c'est une présentation très bien faite sur les jointures.)
Est-il vraiment nécessaire de tout ramener?
Si oui, 58 secondes, cela ne me choque pas a priori. (Par contre l'absence de clé étrangère, et la clé technique sur user_parutions me dérangent)
Pour le support commercial, il y a :
http://www.postgresql.fr/support:start
Florence COUSIN
From | Date | Subject | |
---|---|---|---|
Next Message | Cédric Villemain | 2012-01-20 14:21:12 | Re: Performances fetchs 3.5M lignes |
Previous Message | Pierre Y. | 2012-01-20 13:00:29 | Performances fetchs 3.5M lignes |