[postgis-devel] 1.3.3

[Paul Ramsey]

The problem is that the memcmp hit gets worse in exactly the cases
were we expect better and better performance from the prepared
algorithm...  still, it would be nice to know what that hit is...
compared to the original, unprepared time, it will be small, but
compared to the prepared-with-id-API implementation... hard to say.

Something to resolve before 1.4... It's unfortunate that all the
*fast* tests can only falsify identity, not confirm it.  I was talking
to a fellow who has done a spatial db implementation on a proprietary
system, and he was pleased with the idea of a "geographic hash" that
he can calculate for each shape and use to test identity.  If we were
to do something like that, it would have to be optional, like the bbox
calculation is currently.

P.

On Mon, Mar 31, 2008 at 2:51 AM, Mark Cave-Ayland
<mark.cave-ayland at siriusit.co.uk> wrote:
> On Friday 28 March 2008 23:53:53 Ben Jubb wrote:
>  > Howdy,
>  > In my testing, I did see a performance hit when using the memcmp test,
>  > although it was noticable only in the largest of my test geometries
>  > (5000 vertices or so).
>  > The three parameter form seemed like the best way to go because the
>  > whole point of the prepared version of the functions was to get the best
>  > possible performance.  The cases when the performance matters most is
>  > with large geoms, and then the cost of doing the memcmp is the highest.
>  > Using a third argument seemed the simplest way to get the best possible
>  > performance from the predicates, with a minimal increase in the
>  > complexity of the interface.
>  > I agree it would be nice to have a single form for those predicates that
>  > automatically determines the most efficient manner to do the tests, but
>  > there didn't seem to be any efficient way to accomplish that.
>  >
>  > b
>
>
>  Hi Ben,
>
>  Well I think it really comes down to what exactly is the performance hit and
>  how did you measure it? Which platform/OS/C library did you use? Obviously
>  there will be *some* overhead having the extra memcmp() in there but does it
>  matter? For example, if the overhead is just 1-2s on a 30s query then that
>  doesn't really matter. Then again, if the overhead is 1s on a 3s query then
>  that is significant.
>
>  Since this is a new feature then I'd be inclined to say that for a first cut
>  we should keep the standard API, and depending on the reports we get back,
>  look at improving it later. That seems a lot more preferable to having a
>  fairly nasty API hack that will catch a lot of people out :(
>
>
>
>  ATB,
>
>  Mark.
>
>  --
>  Mark Cave-Ayland
>  Sirius Corporation - The Open Source Experts
>  http://www.siriusit.co.uk
>  T: +44 870 608 0063
>  _______________________________________________
>  postgis-devel mailing list
>  postgis-devel at postgis.refractions.net
>  http://postgis.refractions.net/mailman/listinfo/postgis-devel
>