<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Jun 29, 2017 at 10:31 PM, Regina Obe <span dir="ltr"><<a href="mailto:lr@pcorp.us" target="_blank">lr@pcorp.us</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><a href="https://postgis.net/docs/performance_tips.html#small_tables_large_objects" rel="noreferrer" target="_blank">https://postgis.net/docs/<wbr>performance_tips.html#small_<wbr>tables_large_objects</a><br>
<br>
This is the last bit of business before I can release PostGIS 2.3.3.<br>
<br>
I'd like to get rid of this whole discussion of TOAST as I don't think it's<br>
relevant anymore.<br>
<br>
Am I correct in assuming that?<br>
<br>
My assumption of why I think it's not relevant anymore is that we store<br>
cached boxes for most geometries except for Points and 2 point lines.<br>
So isn't it so that even if there is no index on a geometry, we do not need<br>
to fully detoast (or possibly not to detoast at all) the geometry to read<br>
the bounding box.<br>
That it is part of the head of the geometry?<br></blockquote><div><br></div><div>No, that is not so. If the object is large enough that it requires toasting, the whole thing is stuffed off to the side table and replaced with a reference in the main tuple. In order to get at that bbox on the header, we have to .... go to the toast tables and re-assemble the thing. </div><div><br></div><div>"Worse", since we use compression on large objects, the object is compressed in the side tables and is pulled back in its entirety, then decompressed, then just the header is read.</div><div><br></div><div>Changing that would involve storing objects uncompressed and implementing any compression we wanted internal to the postgis library. So we'd have some logic to compress anything larger than N vertices, but would always leave the header uncompressed so we could peak at it for free.</div><div><br></div><div>That would *still* leave the toasting problem, which I'd have to re-confirm whether a pg_datum_slice cleanly pulls out just one piece of the toasted object or actually pulls the whole thing back first.</div><div><br></div><div>P.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
I did a quick test of my states table - 52 records (granted they aren't<br>
huge, but toast size is about 14 MB)<br>
<br>
When I do something like below without forcing enable_seqscan = false; it<br>
doesn't use an index (well sometimes it does even without urging)<br>
<br>
SELECT stusps<br>
from tiger_data.state_all<br>
WHERE the_geom &&<br>
ST_Buffer('<wbr>0101000020AD100000242F4BF94627<wbr>54C0BD0F7DA33F524340'::<wbr>geometry,<br>
5);<br>
<br>
But whether it uses an index or not, the timing is still about the same -<br>
under 10ms.<br>
<br>
Though interestingly switching to<br>
<br>
SELECT stusps<br>
FROM tiger_data.state_all<br>
WHERE ST_Intersects(the_geom,<br>
ST_Buffer('<wbr>0101000020AD100000242F4BF94627<wbr>54C0BD0F7DA33F524340'::<wbr>geometry,<br>
5));<br>
<br>
Does always force an index scan.<br>
<br>
<br>
Thanks,<br>
Regina<br>
<br>
<br>
______________________________<wbr>_________________<br>
postgis-devel mailing list<br>
<a href="mailto:postgis-devel@lists.osgeo.org">postgis-devel@lists.osgeo.org</a><br>
<a href="https://lists.osgeo.org/mailman/listinfo/postgis-devel" rel="noreferrer" target="_blank">https://lists.osgeo.org/<wbr>mailman/listinfo/postgis-devel</a></blockquote></div><br></div></div>