In fact my first intention was to evaluate the performances of the two different cases: querying time and space with separate index, and then with a unique spatio-temporal index. Do spatio-temporal queries, in this second case, can be performed even if the spatial and temporal query data are stored as separate column? Or is this cube type a special data type with a related index type?

<br>In my spatio-temporal schema are even defined in different tables, that have to be joined when executing the access query.<br><br>Best regards,<br>-Elena <br><br><div><span class="gmail_quote">On 8/7/07, <b class="gmail_sendername">

Chris Hodgson</b> <<a href="mailto:chodgson@refractions.net">chodgson@refractions.net</a>> wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">

You didn't mention if you would be doing spatio-temporal queries, ie.<br>querying for objects which existed within a certain region of time and<br>space. For these types of queries, the cube type and index which is<br>

provided in the postgres-contrib package is quite effective. You can store your x,y coordinates in the first two dimensions of the cube,and the date/time in the third dimension. The gist-based cube indexes are are very fast, but do consume a lot of disk space.

<br><br>If you're only querying based on date then a standard b-tree index on<br>the date itself should provide reasonable performance.<br><br>Chris<br><br>Elena Camossi wrote:<br>> Hi list,<br>><br>> I'm designing a spatio-temporal schema with support for coverage and

<br>> temporal data in postgresql by using postgis spatial extension. The<br>> temporal support so far is quite limited,  just timestamps which state<br>> the time at which data have been collected. Anyway, the temporal

> information is extensively used to access data, so the corresponding > fields should require an index. > > The scientific literature states that R-Tree perform quite well with > this kind of data, but there exist other indexes that should perform better.

<br>> Does anyone in the list has some previous experience on using GiST<br>> postgres implementation for indexing postgresql temporal columns? Does<br>> anyone extend the GiST operator classes with specific support for

<br>> temporal data?<br>><br>> Thank you for helping.<br>><br>> Best regards,<br>> -Elena<br>><br>><br>> ------------------------------------------------------------------------<br>><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>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></blockquote></div><br>