<div dir="ltr"><div>Hi Daniel,<br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Il giorno dom 24 gen 2021 alle ore 18:16 Daniel Baston <<a href="mailto:dbaston@gmail.com">dbaston@gmail.com</a>> ha scritto:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>Hi Giuseppe,</div><div><br></div><div>You can order the inputs by anything you like; OVER(ORDER BY feature_id) would work just as well. If you have an example that is not deterministic despite ordered inputs, I'd be curious to see it if you can share.<br></div></div></blockquote><div><br></div><div>Sorry for the delay of my reply, but I took the opportunity to run some more testing on this. Basically, I found the origin of the issue on our side: we use the DBSCAN algorithm as part of a data pipeline which creates<br>PG instances "on the fly" in order to build the geospatial data. The not deterministic behaviour is not present if for instance we avoid to switch on/off the PG instance. Probably in this configuration it is able to access</div><div>the data in memory always sorted in the same way. We are currently studying if adding the ORDER BY clause helps in having it deterministic even recreating the PG instance on the fly.<br><br></div><div>Thanks for your help.<br></div><div>Giuseppe.<br></div></div></div>