[postgis-users] GIST index speed

Mark Cave-Ayland mark.cave-ayland at siriusit.co.uk
Mon Jun 9 05:39:34 PDT 2008


Mark Cave-Ayland wrote:

> *blinks* this is definitely a bug somewhere - there is no way that 
> adding a function wrapper to a constant should make the query several 
> orders of magnitude quicker :(

Hmmm. It seems the problem is related to whether or not we copy the 
incoming geometry. I've just created a really simple dummy function that 
  copies the input geometry to a new memory location that looks like this:


Datum LWGEOM_mcatest(PG_FUNCTION_ARGS);
PG_FUNCTION_INFO_V1(LWGEOM_mcatest);
Datum LWGEOM_mcatest(PG_FUNCTION_ARGS)
{
         PG_LWGEOM *pgl = (PG_LWGEOM *)
		PG_DETOAST_DATUM(PG_GETARG_DATUM(0));
         void *mem;

         /* Copy somewhere else */
         mem = palloc(VARSIZE(pgl));
         memcpy(mem, pgl, VARSIZE(pgl)-VARHDRSZ);

         PG_RETURN_POINTER(mem);
}


CREATE OR REPLACE FUNCTION mcatest(geometry)
         RETURNS geometry
         AS '$libdir/lwpostgis','LWGEOM_mcatest'
         LANGUAGE 'C' IMMUTABLE STRICT;


If I then do:

postgis=# explain analyze select count(*) from geography where centroid 
&& (select mcatest(the_geom) from geography where id=69495);
 
QUERY PLAN
-----------------------------------------------------------------------------------------------------------------------------------------------------
  Aggregate  (cost=7157.29..7157.30 rows=1 width=0) (actual 
time=664.406..664.408 rows=1 loops=1)
    InitPlan
      ->  Seq Scan on geography  (cost=0.00..7149.00 rows=1 width=4559) 
(actual time=181.347..182.944 rows=1 loops=1)
            Filter: (id = 69495::numeric)
    ->  Index Scan using geography_geom_centroid_idx on geography 
(cost=0.00..8.28 rows=1 width=0) (actual time=183.543..580.966 
rows=32880 loops=1)
          Index Cond: (centroid && $0)
          Filter: (centroid && $0)
  Total runtime: 666.027 ms
(8 rows)


...then I end up with the shorter time query plan??! I think I will punt 
this one over to pgsql-hackers to see if they can help work out where 
the problem lies.


ATB,

Mark.

-- 
Mark Cave-Ayland
Sirius Corporation - The Open Source Experts
http://www.siriusit.co.uk
T: +44 870 608 0063



More information about the postgis-users mailing list