Stefano,
yes, this is quite acceptable, and makes the relationship between the
two pull requests clearer.
Kind regards,
Ben.
On 23/09/16 10:46, Stefano Costa wrote:
> I wasn't sure if I should open a ticket on GeoServer's JIRA as well... in
> the end, I opted not to and rather refer to the
Hi Rini,
thank you and all others who provided feedback.
I have finally managed to clean up the code, add a few more unit tests and
docs.
Here is the GeoTools PR:
https://github.com/geotools/geotools/pull/1319
...and here is the GeoServer PR:
https://github.com/geoserver/geoserver/pull/1847
I
Stefano,
Indeed, that makes sense, the optimiser should indeed do the work for
you. It's good to see there are vast performance improvements. Good work!
Regards
Niels
On 09/13/2016 10:04 PM, Stefano Costa wrote:
Hi Niels,
we went with the "where exists" subquery approach because it was
Hi Niels,
we went with the "where exists" subquery approach because it was easier to
translate filters to SQL that way. For example, let's think of a filter
which is actually a logical combination (OR / AND) of multiple filters;
each filter could refer to a completely different feature chain, and
Hi Stefano,
I think it is great you added that feature! A vast improvement to the
work that I always had hoped would still be developed.
Out of curiosity, why did you choose the "where exists" clauses rather
than the simple joins that I suggested? You think it has better
performance (I
Hi Ben,
thanks for the quick response. Please, read my comments inline.
On Mon, Sep 12, 2016 at 3:35 AM, Ben Caradoc-Davies
wrote:
> However, I do not claim to understand it all, and I would like to hear
> Niels' and Rini's opinion as they have much deeper understanding of
Stefano,
that looks great to me. A solid piece of work that likely brings large
performance improvements for some common use-cases. However, I do not
claim to understand it all, and I would like to hear Niels' and Rini's
opinion as they have much deeper understanding of joining.
I can confirm