maria-developers team mailing list archive

[Roberto Spadim <roberto@xxxxxxxxxxxxx>]

Hi mateusz, i'm a user and a hobby developer... i will answer with what i
know


2013/9/23 Mateusz Loskot <mateusz@xxxxxxxxxx>

> Hi,
>
> I'm going to ask question about how the current Spatial Extensions are
> implemented.
> I have spent some time reading the source code in the current trunk
> (spatial.h|cc, gcal*.h|cc, related Field and Item definitions, etc.),
> so I have a rough understanding of the overall structure, how the
> geometry data types are implemented and exposed to SQL, how the
> spatial functions are defined and registered. I did not looked into
> details of implementation of geospatial algorithms, but that's too low
> level for the question I'm going to ask.
>
> Initially, I was going to ask very detailed question, listing all the
> relevant code definitions and asking separately about each of them,
> but that's not necessary at this stage, I think.
>
> Instead, I'm going to simplify and ask about the bigger picture, more
> about MariaDB extensions API:
>
> 1. Is it possible to implement MariaDB extensions like Spatial (custom
> type + set of functions) without such a tight coupling with the
> internal implementation of the type system (without messing Field
> class with geometry types directly, etc.)?
>

i think this is something interesting, check this idea:
https://mariadb.atlassian.net/browse/MDEV-4912
well this MDEV is too far from today (it's an idea to mariadb 10.1 we are
at 10.0.5 today...)
forget this MDEV... you can extend mariadb with your hands too :)



>
> 2. Is it possible to implement Spatial using User-Defined Functions
> (UDF) defined in shared binary?
>
yes, the field type probably will be a WKB value and a STRING/BLOB (char)
type, must check i never used a UDF for spatial data



>
> 3. What is the reason behind using Well-Known-Binary (WKB) stream of
> bytes to transport geometry values into/from functions? Is it due to
> limitations of MariaDB type system where String is  the only universal
> carrier for complex data? This concern is related to necessity of
> encoding/decoding WKB when chaining spatial function calls, and
> possibilities to avoid it.
>

internally (at memory / disk) you have a string (for spatial type it's a
WKB format string), and at run/compile/design time you have a class (many
functions) that handle this type (string in this case)

check that at cpu we have only primitive types (java work with something
similar to this too), in other words at memory we have
string/uint/boolean/structs/etc, there's no 'geometric' type at hardware
level...

if you have contact with microcontrollers or linux kernel source or gcc
source, you will know how a C++ language is 'converted' to a
assembler/machine language, and you will understand how a C++ object is
implemented at low level...

in "low words": a class in any computer language is: "protected" memory +
"protected" functions that handle this memory

about why use WKB or other type? well i don't know if we have hardware
(cpu) optimizations here, but at least we have a small memory footprint
(and probably a smaller cpu consume), some languages/cpu have optimizations
to handle for example a math function using int*int, check about SIMD at
wikipedia (http://en.wikipedia.org/wiki/SIMD), or maybe you remember the
pentium with "MMX", it's a hardware optimization for some especific
operations, check SSE, SSE2, etc... the goal is a faster execution, it's
not a limit at mysql/mariadb source code, but a optimization knowing how a
C/C++ language work at low level is the best way to optimize memory and cpu


>
> Best regards,
> --
> Mateusz  Loskot, http://mateusz.loskot.net
> "Participation in this whole process is a form of torture" ~~ Szalony
>
> _______________________________________________
> Mailing list: https://launchpad.net/~maria-developers
> Post to     : maria-developers@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~maria-developers
> More help   : https://help.launchpad.net/ListHelp
>


well i don't know if every thing i wrote is ok hehe, but it's a high level
guide line :)


-- 
Roberto Spadim