What's a good way to improve this query?

From: Jorge Arévalo <jorgearevalo(at)libregis(dot)org>
To: pgsql-general(at)postgresql(dot)org
Subject: What's a good way to improve this query?
Date: 2013-06-05 18:22:26
Message-ID: E7B2921EF4AA47E8A7B28A24681032A9@libregis.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

Hello,

I'm running this PostGIS Raster query

select
st_scalex(rast),
st_scaley(rast),
st_skewx(rast),
st_skewy(rast),
st_width(rast),
st_height(rast),
rid,
st_upperleftx(rast),
st_upperlefty(rast),
st_numbands(rast)
from
my_postgis_raster_table

I want to remark that, even when 'rast' is a complex type and can be really big, I'm getting just metadata. Not the whole 'rast' column. Anyway, the average dimensions of a 'rast' column in like 600x400 pixels (8 bits per pixel). So, not so big (about 234 KB per rast object).

My table has 1257 rows, and this query takes about 45 secs to execute (45646 msecs). I think it's too slow. I'm just getting metadata, not the whole 'rast' object, as said.

This is the explain analyze output

Seq Scan on my_postgis_raster_table (cost=0.00..198.85 rows=1257 width=36) (actual time=86.867..51861.495 rows=1257 loops=1)
Total runtime: 51863.919 ms

So, basically a sequential scan. As expected, I guess (I'm not a postgres expert, so sorry if I'm talking nonsense)

I've calculated the effective transfer rate for this table

SELECT pg_size_pretty(CAST(pg_relation_size('my_postgis_raster_table') / 45646 * 1000 as int8)) AS bytes_per_second;

As it's 27KB. Isn't it a slow rate? Is there any kind of index I could create to speed this query? Maybe use some kind of cache system?

Many thanks in advance,

--
Jorge Arevalo
Freelance developer

http://www.krop.com/jorgearevalo
http://about.me/jorgeas80

Enviado con Sparrow (http://www.sparrowmailapp.com/?sig)

Responses

Browse pgsql-general by date

  From Date Subject
Next Message BladeOfLight16 2013-06-05 18:28:36 point_ops with GiST PostGIS Spatial Index
Previous Message Mike Summers 2013-06-05 14:36:43 Re: View's plan not taking advantage of WHERE?