<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">

<html><head>

    <meta http-equiv="Content-Type" content="text/html; charset=utf-8">

    <meta name="generator" content="Osso Notes">

    <title></title></head>

<body>

Wow!

<br>

I have not understood this will be in place for 2.0.

<br>

<br>Great :-)

<br>

<br>/Nicklas

<br>

<br>----- Original message -----

<br>> Well, I have my first proof-of-concept test turning over using the

<br>> GSERIALIZED index binding, shared with geography, on a geometry table

<br>> (the operator is a triple &&& to avoid colliding with the existing

> one, for now).

<br>> 

<br>> Nothing working is committed yet, but it's getting closer. I think

<br>> next I need to work through the online regression failures that occur

<br>> when GSERIALIZED_ON is set. Then I should be able to flip over to the

> new format relatively quickly.

<br>> 

<br>> Now, the new index is multi-dimensional, which means it builds out to

<br>> the maximum dimensionality necessary to index the inputs. That is all

<br>> good. An interesting issue occurs when querying it, however... as it

<br>> stands, if you query a 3d table with a 2d object, the 2d object is

<br>> projected onto the zero plane of the higher dimensions and then the

<br>> query is run. So the query below carried out with a 2d linestring

<br>> returns no answers. The solution is pretty clear in changing the

<br>> gidx_overlaps and gidx_contains function definitions, but it's a core

<br>> change to the existing index, so I will proceed carefully. The change

<br>> will cause lower dimensional objects to have full coverage of the

<br>> higher dimensions, so a 2d object will operate like a cylinder in the

> higher space, rather than a piece of paper.

<br>> 

<br>> Fun fun, maybe we'll have a Christmas Miracle (n-d indexing and

> gserialized storage committed and working).

<br>> 

<br>> Paul

<br>> 

<br>> 

<br>> postgis20=# select count(*) from random_points where pt &&&

<br>> 'LINESTRING(10000 10000 10000, 20000 20000 20000)'::geometry;

<br>>   count

<br>> -------

<br>>           2

<br>> (1 row)

<br>> 

<br>> postgis20=# explain analyze select count(*) from random_points where

<br>> pt &&& 'LINESTRING(10000 10000 10000, 20000 20000 20000)'::geometry;

<br>> 

<br>>           QUERY PLAN

<br>> -------------------------------------------------------------------------------------------------------------------------------------------------------------------

<br>>   Aggregate   (cost=39301.62..39301.63 rows=1 width=0) (actual

<br>> time=1.360..1.360 rows=1 loops=1)

<br>>       ->   Bitmap Heap Scan on random_points   (cost=22455.62..38051.62

<br>> rows=500000 width=0) (actual time=1.347..1.349 rows=2 loops=1)

<br>>                   Recheck Cond: (pt &&&

<br>> '010200008002000000000000000088C340000000000088C340000000000088C340000000000088D340000000000088D340000000000088D340'::geometry)

<br>>                   ->   Bitmap Index Scan on rpg   (cost=0.00..22330.62

<br>> rows=500000 width=0) (actual time=1.336..1.336 rows=2 loops=1)

<br>>                               Index Cond: (pt &&&

<br>> '010200008002000000000000000088C340000000000088C340000000000088C340000000000088D340000000000088D340000000000088D340'::geometry)

<br>>   Total runtime: 1.458 ms

<br>> (6 rows)

<br>> _______________________________________________

<br>> postgis-devel mailing list

<br>> <a href="mailto:postgis-devel@postgis.refractions.net">postgis-devel@postgis.refractions.net</a>

<br>> <a href="http://postgis.refractions.net/mailman/listinfo/postgis-devel">http://postgis.refractions.net/mailman/listinfo/postgis-devel</a>

<br>> 

<br><br></p>

</body>

</html>