<div dir="ltr"><div><div>great catch,<br></div>such speed enhancement would be of much help working with postgis raster .<br></div>Cheers,<br>Rémi-C<br></div><div class="gmail_extra"><br><br><div class="gmail_quote">2014-06-23 13:12 GMT+02:00 Sandro Santilli <span dir="ltr"><<a href="mailto:strk@keybit.net" target="_blank">strk@keybit.net</a>></span>:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I'm playing with GDAL driver for postgis raster and trying to understand<br>
how to speed it up. During the inspection, I found that the PostgreSQL-9.3<br>
panner makes bad choices when it comes to select a portion of the tileset.<br>
<br>
The table has 2048 rows.<br>
The query selects 128 of them.<br>
The query uses:<br>
<br>
  "rast" && ST_GeomFromText(..)<br>
<br>
Creating an index on ((rast::geometry)) makes the index a possible choice,<br>
but the planner decides to use a sequencial scan, which takes ~1 second:<br>
<br>
 Seq Scan on hyp_lr  (cost=0.00..206.75 rows=410 width=29) (actual time=927.443..1078.541 rows=128 loops=1)<br>
   Filter: ((rast)::geometry && '0103000000010000000500000000000000008066C030939999991954C03AF9FFFFFF7F664030939999991954C03AF9FFFFFF7F664090F9FFFFFF3F54C000000000008066C090F9FFFFFF3F54C000000000008066C030939999991954C0'::geometry)<br>

   Rows Removed by Filter: 1920<br>
 Total runtime: 1078.588 ms<br>
<br>
Disabling sequencial scans generates a plan that executes in ~0.06 seconds<br>
instead:<br>
<br>
 Bitmap Heap Scan on hyp_lr  (cost=27.32..209.50 rows=410 width=29) (actual time=0.840..59.696 rows=128 loops=1)<br>
   Recheck Cond: ((rast)::geometry && '0103000000010000000500000000000000008066C030939999991954C03AF9FFFFFF7F664030939999991954C03AF9FFFFFF7F664090F9FFFFFF3F54C000000000008066C090F9FFFFFF3F54C000000000008066C030939999991954C0'::geometry)<br>

   ->  Bitmap Index Scan on hyp_lr_rast_idx  (cost=0.00..27.22 rows=410 width=0) (actual time=0.113..0.113 rows=128 loops=1)<br>
         Index Cond: ((rast)::geometry && '0103000000010000000500000000000000008066C030939999991954C03AF9FFFFFF7F664030939999991954C03AF9FFFFFF7F664090F9FFFFFF3F54C000000000008066C090F9FFFFFF3F54C000000000008066C030939999991954C0'::geometry)<br>

 Total runtime: 59.764 ms<br>
<br>
The dataset is the "Land coloring basd on elevation", medium size:<br>
<a href="http://www.naturalearthdata.com/downloads/10m-raster-data/10m-cross-blend-hypso/" target="_blank">http://www.naturalearthdata.com/downloads/10m-raster-data/10m-cross-blend-hypso/</a><br>
<br>
The "funny" thing is that if I create a vector-only table with the<br>
output of rast::geometry, the planner makes a good choice (and better<br>
estimation):<br>
<br>
 Bitmap Heap Scan on test_planner  (cost=4.20..23.50 rows=7 width=120) (actual time=0.077..0.122 rows=128 loops=1)<br>
   Recheck Cond: (g && '0103000000010000000500000000000000008066C030939999991954C03AF9FFFFFF7F664030939999991954C03AF9FFFFFF7F664090F9FFFFFF3F54C000000000008066C090F9FFFFFF3F54C000000000008066C030939999991954C0'::geometry)<br>

   ->  Bitmap Index Scan on test_planner_g_idx  (cost=0.00..4.20 rows=7 width=0) (actual time=0.066..0.066 rows=128 loops=1)<br>
         Index Cond: (g && '0103000000010000000500000000000000008066C030939999991954C03AF9FFFFFF7F664030939999991954C03AF9FFFFFF7F664090F9FFFFFF3F54C000000000008066C090F9FFFFFF3F54C000000000008066C030939999991954C0'::geometry)<br>

 Total runtime: 0.192 ms<br>
<br>
Is this a problem with the estimator, you think ?<br>
Can you imagine a way to make it smarter ?<br>
<br>
--strk;<br>
<br>
 ()  ASCII ribbon campaign  --  Keep it simple !<br>
 /\  <a href="http://strk.keybit.net/rants/ascii_mails.txt" target="_blank">http://strk.keybit.net/rants/ascii_mails.txt</a><br>
_______________________________________________<br>
postgis-devel mailing list<br>
<a href="mailto:postgis-devel@lists.osgeo.org">postgis-devel@lists.osgeo.org</a><br>
<a href="http://lists.osgeo.org/cgi-bin/mailman/listinfo/postgis-devel" target="_blank">http://lists.osgeo.org/cgi-bin/mailman/listinfo/postgis-devel</a><br>
</blockquote></div><br></div>