>From: "Bryan Harper" <BHarper@...>

[ Request for spatial support ]

I assume you are talking about using something like R-trees as an access
method to support multidimensional queries. Is that what you are after, or
is just being able to express the query enough? If you just want to be able
to express the query, a UDF is probably just fine. Otherwise:

This also raises the whole object relational question. User defined
datatypes, operator overloading, etc. I suspect that retrofitting this is a
lot of work, some of which can be done through UDFs, but to do it properly
there would be an impact on the engine.

Given that we can't see the source code yet, we can't really see what would
be involved. I have some guesses:

- The b-tree implementation (and the rest of the engine) probably has a
built in understanding of datatypes and primitive operators. Extending this
to support user defined types would be a reasonable effort.
- B-tree interior node key comparison and prefix and suffix compression
would change according to the overloading. Giving the b-tree module access
to higher level (and user defined) knowledge would be work, but would also
(for example) avoid the problems of non-english collation orders creating
huge keys. At the moment, my guess is that the keys must be represented so
that the ordering is correct based on a binary comparison.
- Supporting abstract datatypes would certainly involve changes thoughout.
- The optimiser probably has a very fixed view of access paths.

It is difficult to talk about this without real knowledge of the source
code.

I have also have an unrelated question: Does the super server
implementation use one thread per connection, or is there a pool of threads
looping around a select call (or its equivalent)? I know I could just
connect to an engine and count the threads, but I haven't bothered. :-)

Jan Mikkelsen
janm@...