ST_Distance n'utilise pas d'index pour la requête spatiale

10

Je ne peux pas faire fonctionner PostGIS 2.1 sur PostgreSQL 9.3.5 pour utiliser un index spatial même pour les requêtes les plus simples. L' ensemble de données est de 8 millions de points (grille de dénombrement de la population d'ici) . Le tableau est créé en tant que

CREATE TABLE points (
    population DOUBLE PRECISION NOT NULL,
    location GEOGRAPHY(4326, POINT) NOT NULL
)
CREATE INDEX points_gix ON points USING GIST(location);

Les requêtes sont aussi simples que possible

SELECT SUM(population)
FROM points
WHERE ST_Distance(
    location,
    ST_GeographyFromText('SRID=4326; POINT(0 0)')
) < 1000

PostgreSQL utilise toujours le scan Seq pour cela, j'ai essayé un sous-ensemble avec 10000 points - toujours le scan Seq. Des idées?

postgis postgresql spatial-index st-distance st-dwithin synapse
la source
3
Vous n'utilisez aucune fonction pouvant utiliser l'index. Utilisez plutôt st_dwithin. Ensuite, la fonction fera d'abord un balayage d'index.
Nicklas Avén
Réfléchissez à ce que fait votre requête - calculer la distance entre chaque point d'une table et un point fixe - et vous comprendrez pourquoi aucun index ne peut être utilisé. Utilisez plutôt un opérateur qui peut utiliser un index, comme ST_DWithin
Vince

Réponses:

19

ST_Distance calcule en fait la distance entre toutes les paires de points, donc, en tant que tel, aucun index n'a pu être utilisé. Votre requête effectuera donc un balayage de séquence, puis choisira les géométries qui sont inférieures à la distance que vous spécifiez. Vous recherchez ST_DWithin , qui utilise un index.

SELECT SUM(population) FROM points 
WHERE ST_DWithin(location, ST_GeographyFromText('SRID=4326; POINT(0 0)'), 1000);

ST_Distance est plus utile pour classer les résultats, souvent conjointement avec ORDER BY et / ou LIMIT, qui ont été obtenus avec des requêtes qui utilisent un index.

John Powell
la source
1
Merci. Je devrais vraiment lire les documents avant de poser des questions.
synapse
1
HOU LA LA! MERCI! Vous venez d'accélérer ma requête lente comme 100 fois ou plus en raison de la modification de st_distance en st_dwithin. (Je dis "accéléré" parce que cela n'aurait jamais dû arriver en premier si j'avais été plus prudent)
Hendy Irawan
1
@HendyIrawan. Je vous en prie. C'est une erreur facile à faire.
John Powell
@ JohnPowellakaBarça J'ai ajouté une autre optimisation (bien que très perdante , j'ai ajouté une réponse pour mon cas) mais vous m'avez pointé dans la bonne direction, merci.
Hendy Irawan
4

Comme l'a dit @ JohnPowellakaBarça, ST_DWithin()c'est la voie à suivre lorsque vous voulez être correct .

Cependant, dans mon cas, je ne veux qu'une estimation approximative, donc même ST_DWithin()trop cher (en coût de requête) pour mes besoins. J'ai utilisé &&et ST_Expand(box2d)(ne confondez pas cela avec la geometryversion) à la place. Exemple:

SELECT * FROM profile
  WHERE
    address_point IS NOT NULL AND
    address_point && CAST(ST_Expand(CAST(ST_GeomFromText(:point) AS box2d), 0.5) AS geometry;

Ce qui sera immédiatement évident, c'est que nous avons affaire à des degrés plutôt qu'à des mètres et à l'utilisation d'un cadre de délimitation au lieu d'un cercle dans un sphéroïde. Pour mon cas d'utilisation, cela passe de 24 ms à seulement 2 ms (localement en SSD). Cependant, pour ma base de données de production dans AWS RDS PostgreSQL avec des connexions simultanées et des quotas IOPS à peine généreux (100 IOPS), la ST_DWithin()requête d' origine dépense trop d'IOPS et peut s'exécuter plus de 2000 ms et bien pire lorsque le quota d'IOPS est épuisé.

Ce n'est pas pour tout le monde mais au cas où vous pourriez sacrifier une certaine précision pour la vitesse (ou pour économiser les IOPS), alors cette approche pourrait être pour vous. Comme vous pouvez le voir dans les plans de requête ci-dessous, ST_DWithinnécessite toujours un filtre spatial à l'intérieur du Bitmap Heap Scan en plus de Recheck Cond, tandis que &&sur une boîte, la géométrie n'a pas besoin de Filter et utilise uniquement Recheck Cond.

J'ai également remarqué que IS NOT NULLce qui compte, sans lui, vous vous retrouverez avec un pire plan de requête. Il semble que l'indice GIST ne soit pas "assez intelligent" pour cela. (bien sûr, ce n'est pas nécessaire si votre colonne est NOT NULL, dans mon cas, c'est NULLpossible)

Table de 20000 lignes, ST_DWithin(geography, geography, 100000, FALSE)sur AWS RDS 512 Mo de RAM avec 300 IOPS:

Aggregate  (cost=4.61..4.62 rows=1 width=8) (actual time=2011.358..2011.358 rows=1 loops=1)
  ->  Bitmap Heap Scan on matchprofile  (cost=2.83..4.61 rows=1 width=0) (actual time=1735.025..2010.635 rows=1974 loops=1)
        Recheck Cond: (((address_point IS NOT NULL) AND (address_point && '0101000020E6100000744694F606E75A40D49AE61DA7A81BC0'::geography)) OR ((hometown_point IS NOT NULL) AND (hometown_point && '0101000020E6100000744694F606E75A40D49AE61DA7A81BC0'::geography)))
        Filter: (((status)::text = 'ACTIVE'::text) AND ((gender)::text = 'MALE'::text) AND (((address_point IS NOT NULL) AND (address_point && '0101000020E6100000744694F606E75A40D49AE61DA7A81BC0'::geography) AND ('0101000020E6100000744694F606E75A40D49AE61DA7A81BC0'::geography && _st_expand(address_point, '100000'::double precision)) AND _st_dwithin(address_point, '0101000020E6100000744694F606E75A40D49AE61DA7A81BC0'::geography, '100000'::double precision, false)) OR ((hometown_point IS NOT NULL) AND (hometown_point && '0101000020E6100000744694F606E75A40D49AE61DA7A81BC0'::geography) AND ('0101000020E6100000744694F606E75A40D49AE61DA7A81BC0'::geography && _st_expand(hometown_point, '100000'::double precision)) AND _st_dwithin(hometown_point, '0101000020E6100000744694F606E75A40D49AE61DA7A81BC0'::geography, '100000'::double precision, false))))
        Rows Removed by Filter: 3323
        Heap Blocks: exact=7014
        ->  BitmapOr  (cost=2.83..2.83 rows=1 width=0) (actual time=1716.425..1716.425 rows=0 loops=1)
              ->  Bitmap Index Scan on ik_matchprofile_address_point  (cost=0.00..1.42 rows=1 width=0) (actual time=1167.698..1167.698 rows=16086 loops=1)
                    Index Cond: ((address_point IS NOT NULL) AND (address_point && '0101000020E6100000744694F606E75A40D49AE61DA7A81BC0'::geography))
              ->  Bitmap Index Scan on ik_matchprofile_hometown_point  (cost=0.00..1.42 rows=1 width=0) (actual time=548.723..548.723 rows=7846 loops=1)
                    Index Cond: ((hometown_point IS NOT NULL) AND (hometown_point && '0101000020E6100000744694F606E75A40D49AE61DA7A81BC0'::geography))
Planning time: 47.366 ms
Execution time: 2011.429 ms

Table de 20000 lignes &&et ST_Expand(box2d)sur AWS RDS 512 Mo de RAM avec 300 IOPS:

Aggregate  (cost=3.85..3.86 rows=1 width=8) (actual time=584.346..584.346 rows=1 loops=1)
  ->  Bitmap Heap Scan on matchprofile  (cost=2.83..3.85 rows=1 width=0) (actual time=555.048..584.083 rows=1154 loops=1)
        Recheck Cond: (((address_point IS NOT NULL) AND (address_point && '0103000020E61000000100000005000000744694F606C75A40D49AE61DA7A81DC0744694F606C75A40D49AE61DA7A819C0744694F606075B40D49AE61DA7A819C0744694F606075B40D49AE61DA7A81DC0744694F606C75A40D49AE61DA7A81DC0'::geography)) OR ((hometown_point IS NOT NULL) AND (hometown_point && '0103000020E61000000100000005000000744694F606C75A40D49AE61DA7A81DC0744694F606C75A40D49AE61DA7A819C0744694F606075B40D49AE61DA7A819C0744694F606075B40D49AE61DA7A81DC0744694F606C75A40D49AE61DA7A81DC0'::geography)))
        Filter: (((status)::text = 'ACTIVE'::text) AND ((gender)::text = 'MALE'::text))
        Rows Removed by Filter: 555
        Heap Blocks: exact=3812
        ->  BitmapOr  (cost=2.83..2.83 rows=1 width=0) (actual time=553.091..553.091 rows=0 loops=1)
              ->  Bitmap Index Scan on ik_matchprofile_address_point  (cost=0.00..1.42 rows=1 width=0) (actual time=413.074..413.074 rows=4850 loops=1)
                    Index Cond: ((address_point IS NOT NULL) AND (address_point && '0103000020E61000000100000005000000744694F606C75A40D49AE61DA7A81DC0744694F606C75A40D49AE61DA7A819C0744694F606075B40D49AE61DA7A819C0744694F606075B40D49AE61DA7A81DC0744694F606C75A40D49AE61DA7A81DC0'::geography))
              ->  Bitmap Index Scan on ik_matchprofile_hometown_point  (cost=0.00..1.42 rows=1 width=0) (actual time=140.014..140.014 rows=3100 loops=1)
                    Index Cond: ((hometown_point IS NOT NULL) AND (hometown_point && '0103000020E61000000100000005000000744694F606C75A40D49AE61DA7A81DC0744694F606C75A40D49AE61DA7A819C0744694F606075B40D49AE61DA7A819C0744694F606075B40D49AE61DA7A81DC0744694F606C75A40D49AE61DA7A81DC0'::geography))
Planning time: 0.673 ms
Execution time: 584.386 ms

Encore une fois avec une requête plus simple:

Table de 20000 lignes, ST_DWithin(geography, geography, 100000, FALSE)sur AWS RDS 512 Mo de RAM avec 300 IOPS:

Aggregate  (cost=4.60..4.61 rows=1 width=8) (actual time=36.448..36.448 rows=1 loops=1)
  ->  Bitmap Heap Scan on matchprofile  (cost=2.83..4.60 rows=1 width=0) (actual time=7.694..35.545 rows=2982 loops=1)
        Recheck Cond: (((address_point IS NOT NULL) AND (address_point && '0101000020E6100000744694F606E75A40D49AE61DA7A81BC0'::geography)) OR ((hometown_point IS NOT NULL) AND (hometown_point && '0101000020E6100000744694F606E75A40D49AE61DA7A81BC0'::geography)))
        Filter: (((address_point IS NOT NULL) AND (address_point && '0101000020E6100000744694F606E75A40D49AE61DA7A81BC0'::geography) AND ('0101000020E6100000744694F606E75A40D49AE61DA7A81BC0'::geography && _st_expand(address_point, '100000'::double precision)) AND _st_dwithin(address_point, '0101000020E6100000744694F606E75A40D49AE61DA7A81BC0'::geography, '100000'::double precision, true)) OR ((hometown_point IS NOT NULL) AND (hometown_point && '0101000020E6100000744694F606E75A40D49AE61DA7A81BC0'::geography) AND ('0101000020E6100000744694F606E75A40D49AE61DA7A81BC0'::geography && _st_expand(hometown_point, '100000'::double precision)) AND _st_dwithin(hometown_point, '0101000020E6100000744694F606E75A40D49AE61DA7A81BC0'::geography, '100000'::double precision, true)))
        Rows Removed by Filter: 2322
        Heap Blocks: exact=2947
        ->  BitmapOr  (cost=2.83..2.83 rows=1 width=0) (actual time=7.197..7.197 rows=0 loops=1)
              ->  Bitmap Index Scan on ik_matchprofile_address_point  (cost=0.00..1.41 rows=1 width=0) (actual time=5.265..5.265 rows=5680 loops=1)
                    Index Cond: ((address_point IS NOT NULL) AND (address_point && '0101000020E6100000744694F606E75A40D49AE61DA7A81BC0'::geography))
              ->  Bitmap Index Scan on ik_matchprofile_hometown_point  (cost=0.00..1.41 rows=1 width=0) (actual time=1.930..1.930 rows=2743 loops=1)
                    Index Cond: ((hometown_point IS NOT NULL) AND (hometown_point && '0101000020E6100000744694F606E75A40D49AE61DA7A81BC0'::geography))
Planning time: 0.479 ms
Execution time: 36.512 ms

Table de 20000 lignes &&et ST_Expand(box2d)sur AWS RDS 512 Mo de RAM avec 300 IOPS:

Aggregate  (cost=3.84..3.85 rows=1 width=8) (actual time=6.263..6.264 rows=1 loops=1)
  ->  Bitmap Heap Scan on matchprofile  (cost=2.83..3.84 rows=1 width=0) (actual time=4.295..5.864 rows=1711 loops=1)
        Recheck Cond: (((address_point IS NOT NULL) AND (address_point && '0103000020E61000000100000005000000744694F606C75A40D49AE61DA7A81DC0744694F606C75A40D49AE61DA7A819C0744694F606075B40D49AE61DA7A819C0744694F606075B40D49AE61DA7A81DC0744694F606C75A40D49AE61DA7A81DC0'::geography)) OR ((hometown_point IS NOT NULL) AND (hometown_point && '0103000020E61000000100000005000000744694F606C75A40D49AE61DA7A81DC0744694F606C75A40D49AE61DA7A819C0744694F606075B40D49AE61DA7A819C0744694F606075B40D49AE61DA7A81DC0744694F606C75A40D49AE61DA7A81DC0'::geography)))
        Heap Blocks: exact=1419
        ->  BitmapOr  (cost=2.83..2.83 rows=1 width=0) (actual time=4.122..4.122 rows=0 loops=1)
              ->  Bitmap Index Scan on ik_matchprofile_address_point  (cost=0.00..1.41 rows=1 width=0) (actual time=3.018..3.018 rows=1693 loops=1)
                    Index Cond: ((address_point IS NOT NULL) AND (address_point && '0103000020E61000000100000005000000744694F606C75A40D49AE61DA7A81DC0744694F606C75A40D49AE61DA7A819C0744694F606075B40D49AE61DA7A819C0744694F606075B40D49AE61DA7A81DC0744694F606C75A40D49AE61DA7A81DC0'::geography))
              ->  Bitmap Index Scan on ik_matchprofile_hometown_point  (cost=0.00..1.41 rows=1 width=0) (actual time=1.102..1.102 rows=980 loops=1)
                    Index Cond: ((hometown_point IS NOT NULL) AND (hometown_point && '0103000020E61000000100000005000000744694F606C75A40D49AE61DA7A81DC0744694F606C75A40D49AE61DA7A819C0744694F606075B40D49AE61DA7A819C0744694F606075B40D49AE61DA7A81DC0744694F606C75A40D49AE61DA7A81DC0'::geography))
Planning time: 0.399 ms
Execution time: 6.306 ms
Hendy Irawan
la source
1
Bon écrit et intéressant.
John Powell