<div dir="auto">I am willing to set up a test environment on a arm64 machine to run tests for this.  I did something like this to test the advantage of a distributed database vs stand alone.  If you could set up a matrix on the requirements (function, PG/PostGIS versions, input data, etc.) I could play with it.  It would be a raspberry pi 4, 64 bit, and 4 or 8GB memory.  Doing it via Jenkins would be also possible.  Advantage on the pi is it is slow enough that improvements should be obvious.</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Oct 18, 2022, 3:49 PM Paul Ramsey <<a href="mailto:pramsey@cleverelephant.ca">pramsey@cleverelephant.ca</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Going to track this here <a href="https://trac.osgeo.org/postgis/ticket/5259" rel="noreferrer noreferrer" target="_blank">https://trac.osgeo.org/postgis/ticket/5259</a><br>
<br>
On Tue, Oct 4, 2022 at 7:26 PM Regina Obe <<a href="mailto:lr@pcorp.us" target="_blank" rel="noreferrer">lr@pcorp.us</a>> wrote:<br>
><br>
> > On Mon, Oct 3, 2022 at 9:59 AM Tomas Vondra<br>
> > <<a href="mailto:tomas.vondra@2ndquadrant.com" target="_blank" rel="noreferrer">tomas.vondra@2ndquadrant.com</a>> wrote:<br>
> ><br>
> > ><br>
> > > On 9/29/22 23:11, Paul Ramsey wrote:<br>
> > > > So, historically, we have had these these functions like<br>
> > > > ST_Contains() that have an implicit index operation within them, so<br>
> > > > you could do<br>
> > > ><br>
> > > > SELECT * FROM foo WHERE ST_Contains(geom, ...)<br>
> > > ><br>
> > > > and you'd get an efficient plan, even without adding the magical<br>
> > > > index operator (&&). This was being friendly to our users and<br>
> > > > following the standard for spatial SQL to the letter.<br>
> > > ><br>
> > > > This was accomplished with a SQL function ST_Contains that wrapped<br>
> > > > up the C function _ST_Contains() and the magic operator. This trick<br>
> > > > worked for a long time indeed (and was, in fact, the only solution)<br>
> > > > but it did force us to not "correctly" cost our (really expensive,<br>
> > > > compared to other database functions) spatial functions. When we<br>
> > > > pushed up costs for functions, the planner began to get angry.<br>
> > ><br>
> > > > /*<br>
> > > >  * High costs can only be used for PostGIS 3/PgSQL 12<br>
> > > >  * where the support functions have been used in<br>
> > > >  * place of index SQL inlining.<br>
> > > >  * See <a href="https://trac.osgeo.org/postgis/ticket/3675" rel="noreferrer noreferrer" target="_blank">https://trac.osgeo.org/postgis/ticket/3675</a><br>
> > > >  * for sideffects of costing inlined SQL.<br>
> > > >  */<br>
> > > > #if POSTGIS_PGSQL_VERSION >= 120<br>
> > > > #define _COST_DEFAULT COST 1<br>
> > > > #define _COST_LOW COST 50<br>
> > > > #define _COST_MEDIUM COST 500<br>
> > > > #define _COST_HIGH COST 10000<br>
> > > > #else<br>
> > > > #define _COST_DEFAULT COST 1<br>
> > > > #define _COST_LOW COST 1<br>
> > > > #define _COST_MEDIUM COST 10<br>
> > > > #define _COST_HIGH COST 10<br>
> > > > #endif<br>
> > > ><br>
> > > > With PgSQL 12, we were no longer in-lining, and we could bump up<br>
> > > > those costs without any apparently downside, with the upside that we<br>
> > > > even got more parallel plans for things like joins and so on. So we<br>
> > > > did that.<br>
> > > ><br>
> > > > Notwithstanding that there were some attempts to get metrics on the<br>
> > > > cost of some of our functions, we didn't really do anything<br>
> > > > generating true metrics behind these numbers, except in an<br>
> > > > order-of-magnitude sense, sort of. So there's no moral reason not to<br>
> > > > jimmy with them. What we lack is any sort of way of cross-comparing<br>
> > > > the upsides and downsides of various arbitrary numbers. Maybe we<br>
> > > > should but HIGH_COST in half? Why not? I don't know? Why? Because in<br>
> > > > this case it seems to fit better.<br>
> > > ><br>
> > ><br>
> > > Maybe. I agree our costing model is not really exact science, so maybe<br>
> > > tweaking it a bit is the right thing to do. OTOH once the costs get<br>
> > > into production it's generally harder because it may change behavior<br>
> > > (even if the negative cases are rare).<br>
> > ><br>
> > > > Since the actual cost of these high cost functions is in fact<br>
> > > > incredibly variable (depending on size of inputs) there's no actual<br>
> > > > right answer. Doing some extra work on function level costing could<br>
> > > > potentially make things less variable, but we'd still have an opaque<br>
> > > > function cost multiplier in the equation.<br>
> > > ><br>
> > ><br>
> > > Yeah.<br>
> > ><br>
> > > > I'm tempted to just bump the value down, and see what happens,<br>
> > > > navigating by sonar, as it were, since we lack any other basis for<br>
> > > > these numbers at the moment.<br>
> ><br>
> > Any objections to cutting the HIGH value in half? Honestly we could cut<br>
> all<br>
> > values in half. In main? In 3.3? 3.2? comments?<br>
> ><br>
> > P<br>
> ><br>
> I'd feel more comfortable if we did it only for 3.4 and perhaps do a<br>
> backport later.  I'd like to create some queries in my performance suite to<br>
> try to exercise some of these and would be easier if I can compare 3.4 and<br>
> 3.3, which are largely still the same.<br>
><br>
> I would also half the MEDIUM cost one.<br>
><br>
><br>
> _______________________________________________<br>
> postgis-devel mailing list<br>
> <a href="mailto:postgis-devel@lists.osgeo.org" target="_blank" rel="noreferrer">postgis-devel@lists.osgeo.org</a><br>
> <a href="https://lists.osgeo.org/mailman/listinfo/postgis-devel" rel="noreferrer noreferrer" target="_blank">https://lists.osgeo.org/mailman/listinfo/postgis-devel</a><br>
_______________________________________________<br>
postgis-devel mailing list<br>
<a href="mailto:postgis-devel@lists.osgeo.org" target="_blank" rel="noreferrer">postgis-devel@lists.osgeo.org</a><br>
<a href="https://lists.osgeo.org/mailman/listinfo/postgis-devel" rel="noreferrer noreferrer" target="_blank">https://lists.osgeo.org/mailman/listinfo/postgis-devel</a><br>
</blockquote></div>