Re: requête plus rapide avec une table distante

Dominique Vallée wrote:

> Je donne les liens des explain analyze pour les 2 requêtes :
> table distante fao_areas : http://explain.depesz.com/s/4hO
> select count(*) from tmp_obs_coordgps o, fao_areas f where
> o.code_fao=f.f_code and st_contains(f.the_geom, o.geom);
>
> table locale fao_aires_local : http://explain.depesz.com/s/BvDb
> select count(*) from tmp_obs_coordgps o, fao_aires_local f where
> o.code_fao=f.f_code and st_contains(f.the_geom, o.geom);

D'après l'explain, le distant est logiquement plus lent que le local.

En distant: 293ms pour une lecture totale (le 2eme nombre de actual time)

Foreign Scan on public.fao_areas f (cost=100.00..114.29 rows=143 width=548)
(actual time=203.733..293.851 rows=322 loops=1)

En local: 0.3ms
Seq Scan on public.fao_aires_local f (cost=0.00..88.22 rows=322 width=26,336)
(actual time=0.008..0.320 rows=322 loops=1)

Mais ce n'est pas apparemment pas là-dessus que se joue la différence
globale.

Pour la jointure spatiale le plan rapide fait un Bitmap Heap Scan+Bitmap
Index Scan alors que le plus lent fait un simple Index Scan qui s'avère
coûteux.

Cet index scan mène à: "Buffers: shared hit=20678741".

Est-ce que cet index ne serait pas obèse? Auquel cas un REINDEX pourrait
aider.

Cordialement,
--
Daniel

--
Envoi via la liste pgsql-fr-generale (pgsql-fr-generale(at)postgresql(dot)org)