[postgis-devel] performance test suite

Paul Ramsey pramsey at cleverelephant.ca
Tue May 1 10:08:04 PDT 2018


I think perhaps “do it as a separate project”. It’s going to be complex, it’s going to be brittle, it’s going to eventually break and I’d rather not have it sitting around broken inside the main source tree. The only way to find the regressions is going to be longitudinally testing and keeping track of numbers over time, so it’ll be quite a complex piece of work.

P

> On May 1, 2018, at 10:05 AM, Björn Harrtell <bjorn.harrtell at gmail.com> wrote:
> 
> Hi devs,
> 
> In recent times I've been pondering on about how to make a sensible test suite specifically for performance. Hacking/extending run_test.pl <http://run_test.pl/> to accommodate for this has been the only suggested path forward but to me it's a dead end mostly because of perl (sorry)-
> 
> The reason why this has become a to me apparent missing thing is due to:
> 
> 1. My own work on https://trac.osgeo.org/postgis/ticket/4076 <https://trac.osgeo.org/postgis/ticket/4076>.
> 
> 2. The recently discovered large performance regression of ST_Union tracked by https://trac.osgeo.org/postgis/ticket/4075 <https://trac.osgeo.org/postgis/ticket/4075>. Even if it's in GEOS and could perhaps be performance tested there, I think it would not be wrong to also performance test ST_Union without consideration of underlying implementation.
> 
> Any additional thoughts on the subject? do it in perl or don't do it? :)
> 
> Regards,
> 
> /Björn
> _______________________________________________
> postgis-devel mailing list
> postgis-devel at lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/postgis-devel

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/postgis-devel/attachments/20180501/7e9d6231/attachment.html>


More information about the postgis-devel mailing list