[postgis-devel] Cube Indexes

Mark Cave-Ayland mark.cave-ayland at ilande.co.uk
Tue Aug 15 04:07:01 PDT 2006


On Mon, 2006-08-14 at 09:23 -0700, Paul Ramsey wrote:
> Thanks for the analysis Mark.  I figured there would be an overhead  
> relative to the 2D indexes.  I was actually hoping it would be  
> possible to set up the N-D indexes as an addition to, rather than a  
> replacement of, the 2D indexes (since 95% of use cases only need 2D  
> indexing, it seems a shame to toss them in favor of something 50%  
> heavier).  If we capped the n-dimensionality at 4 (since that is the  
> maximum dimensionality of PostGIS) would that 8-bytes of overhead be  
> smaller?
> 
> P


Hi Paul,

Here is the relevant section from contrib/cube which represents the
N-dimensional box:


typedef struct NDBOX
{
	unsigned int size;			/* required to be a Postgres varlena type */
	unsigned int dim;
	double		x[1];
}


So we'd have to keep the unsigned int in order to function with
PostgreSQL, but we may possibly be able to reduce the dimension element
to an unsigned char to give just over 25% increase in storage space.

My preference would be just to have one set of index methods to cover
all dimensions rather than having multiple copies of some of the most
complex code in PostGIS. Given that most modern systems are now equipped
with sophisticated caching algorithms, and also that index scans are
generally only used to extract small portions of data from a table, in
my opinion there would have to be a very convincing performance
improvement to justify the cost of maintaining multiple index operator
classes, operators and statistics within PostGIS.


Kind regards,

Mark.





More information about the postgis-devel mailing list