[postgis-devel] functions cost, or full table access faster via index !
Sandro Santilli
strk at keybit.net
Fri Aug 15 03:28:55 PDT 2014
For the record, I filed a ticket to raise the COST value for
ST_ConvexHull(raster): http://trac.osgeo.org/postgis/ticket/2895
--strk;
On Fri, Aug 15, 2014 at 12:19:29PM +0200, Sandro Santilli wrote:
> I just found a case in which a sequencial scan with a condition
> selecting _all_ rows takes twice the time it takes for an index scan.
>
> It is a raster table with 178,752 rows.
>
> The query:
>
> select rast from <the_table>
> WHERE rast && <full_extent>
>
> Explains as:
>
> -- With `set enable_seqscan to off`:
>
> Bitmap Heap Scan on timeseq_change00_12_backup (cost=6646.86..71629.06 rows=176816 width=744) (actual time=46.363..10400.507 rows=178752 loops=1)
> Recheck Cond: ((rast)::geometry && '0103000000010000000500000000000000E03953C100000000402434C100000000E03953C10000000000F9254100000000004CFD400000000000F9254100000000004CFD4000000000402434C100000000E03953C100000000402434C1'::geometry)
> -> Bitmap Index Scan on timeseq_change00_12_rast_gist (cost=0.00..6602.65 rows=176816 width=0) (actual time=43.334..43.334 rows=178752 loops=1)
> Index Cond: ((rast)::geometry && '0103000000010000000500000000000000E03953C100000000402434C100000000E03953C10000000000F9254100000000004CFD400000000000F9254100000000004CFD4000000000402434C100000000E03953C100000000402434C1'::geometry)
> Total runtime: 10410.814 ms
>
> -- With `set enable_seqscan to on`:
>
> Seq Scan on timeseq_change00_12_backup (cost=0.00..65490.40 rows=176816 width=744) (actual time=37.168..28962.642 rows=178752 loops=1)
> Filter: ((rast)::geometry && '0103000000010000000500000000000000E03953C100000000402434C100000000E03953C10000000000F9254100000000004CFD400000000000F9254100000000004CFD4000000000402434C100000000E03953C100000000402434C1'::geometry)
> Total runtime: 28974.226 ms
>
> How can an index scan possibly be faster than a sequencial scan when it
> comes to fetching all the rows ?
> Is EXPLAIN ANALYZE not taking into account the actual fetching of the
> output fields ?
>
> I've been thinking that the difference is in the cost of
> (rast)::geometry, which is pre-computed in the case of index access
> while it has to be re-computed for the sequencial access case.
>
> Indeed raising the cost of ST_ConvexHull(raster) to 1000 makes the
> planner pick an index scan, but not with a cost of 100. The current
> cost for ST_ConvexHull(raster) is 1. The cost for ST_ConvexHull(geometry)
> is 100 !
>
> I've seen some raster function are already marked as having a cost of
> 1000 (st_intersects, for example). Should all raster functions have
> a cost of 1000 for the decompression cost ?
>
> How should we deal with cost changes during upgrades ?
>
> --strk;
>
> () ASCII ribbon campaign -- Keep it simple !
> /\ http://strk.keybit.net/rants/ascii_mails.txt
More information about the postgis-devel
mailing list