优化 postgis 查询 - 为什么不使用第二个索引？

Question

We have a table with tens of millions of polygons and we have this index:

CREATE INDEX IF NOT EXISTS polygons_geog_idx ON polygons USING GIST(geog);

That let us query the DB really efficiently, like so:

SELECT * FROM polygons WHERE st_dwithin('SRID=4326;POINT(-1 50)'::geography, geog, 500);

Now due to the business requirements, we need to return only biggest 200 polygons. Easily doable like with:

• LIMIT 200
• ORDER BY st_area(geog)

Full Query: SELECT gid, st_area(geog) as size FROM polygons WHERE st_dwithin(geog, 'SRID=4326;POINT(-1 50)'::geography, 500) ORDER BY st_area(geog) DESC LIMIT 200 .

Because of the order by and select our query slows down by 10x. I thought it will be easily fixable by adding another index like seen in this SO Answer : CREATE INDEX polygons_geog_area_idx ON polygons (st_area(geog));

But polygons_geog_area_idx doesn't seem to be picked up:

Sort  (cost=8.23..8.23 rows=1 width=12) (actual time=133.755..142.427 rows=2325 loops=1)
  Sort Key: (st_area(geog, true))
  Sort Method: quicksort  Memory: 205kB
  ->  Index Scan using polygons_geog_idx on polygons  (cost=0.14..8.22 rows=1 width=12) (actual time=0.468..121.974 rows=2325 loops=1)
        Index Cond: (geog && '0101000020E6100000C33126587787F1BF3B0D62B197654940'::geography)
        Filter: (('0101000020E6100000C33126587787F1BF3B0D62B197654940'::geography && _st_expand(geog, '500'::double precision)) AND _st_dwithin(geog, '0101000020E6100000C33126587787F1BF3B0D62B197654940'::geography, '500'::double precision, true))
        Rows Removed by Filter: 3
Planning Time: 0.157 ms
Execution Time: 151.196 ms

(note: this is on development dataset, much smaller than actual dataset this will run on later)

What am I missing? Can you even use 2 indexes like I want?

Answer 1

PostgreSQL cannot combine two indexes in this way, one for the order and one for selectivity.

In order to sort by the area, it first needs to compute the area. The sort itself is fast (taking only 15% of the time) so it must be the computation of the area which is slow. An EXPLAIN VERBOSE suggests to me that the computation of the area is done as part of the index scan and then the result passed up to the sort, rather than being done in the sort itself. So it makes sense that the timing of doing this would be attributed to the index scan.

To improve the time needed to compute the area, you could compute and store it as part of the table. The best way to do that (with new enough version) is with a generated column.

alter table polygons add polygon_area double precision generated always as (st_area(geog)) stored;