Quoting Mark Cave-Ayland <mark.cave-ayland@siriusit.co.uk>:

> On 07/07/11 10:37, Sandro Santilli wrote:
> 
> >> Indexing derived units in this way does not make sense
> >
> > What if I want to get the list of regions where the average number
> > of mosquitos per year is between  5000 and 10000 ?
> 
> If you are starting to ask those type of queries, then M is not an
> appropriate place for this data - you would spin it out into a separate
> column within your table and index it appropriately there. Then the
> PostgreSQL planner has a lot more information to be able to choose a
> better query plan.

If your query is - In this set of traces, select all the traces within a
specified bounding box that also pass through regions where the mosquito count
is within a given range, then I think it is appropriate to put your data in the
M column, and to index it as 4-D. So I think the semantics of what is a
"dimension" and what is not are dependent on the problem space more that on the
units of the M value.

However I do agree that there are many situations where it doesn't make sense to
index the M value, and it would be nice if there was a way to disable it. And it
also makes sense that these same situations will affect the treatment of the
data by other functions. I'm not certain that the situation of "4-d index makes
sense/is useful" is necessarily the same situation as "4th coordinate is a
'true' dimension". So perhaps there are two separate bits of metadata to capture
there.

Chris


