<div dir="auto">You did that some years ago and ignored my note to update docs: <a href="https://github.com/postgis/postgis/commit/feac7c6ed625bea34de847605a590abdb627bd13">https://github.com/postgis/postgis/commit/feac7c6ed625bea34de847605a590abdb627bd13</a></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">пт, 21 сту 2022, 20:35 карыстальнік Paul Ramsey <<a href="mailto:pramsey@cleverelephant.ca">pramsey@cleverelephant.ca</a>> напісаў:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">A user was talking about how much faster ST_Subdivide made their query, and their example was materializing the subdivided geometries into a table, building an index, and then using that downstream.<br>
<br>
Here's the thing: the default numVertices of ST_Subdivide is 256. Which (256 * 2 * 8 = 4096) is half of a full page, but actually kind of close to the TOAST threshold. At a minimum with standard storage defaults, it'll be getting compressed inline, if not actually TOASTed still. Which will hurt performance.<br>
<br>
I was thinking that a 128 or even 96 point default might make a lot more sense. At 128 vertices (2048 bytes) we're still flirting with inline compression, so maybe 96 (1536b) or even 64 vertices (1024b) would be best.<br>
<br>
In general, it seems like a missed upportunity to have something shredding down geometries but still be over-running the TOAST thresholds, that we know have performance implications, when the whole point of the shredding is improved performance.<br>
<br>
Thoughts?<br>
<br>
P<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>