<div dir="ltr">Hello Marco,<div><br></div><div>Scope for PG13 was fixed half a year ago. This is up for PG14, and needs your care and help to happen - there is a possibility to get it in parallel, since this sorting build is still single thread.</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Sep 17, 2020 at 12:24 AM Marco Boeringa <<a href="mailto:marco@boeringa.demon.nl">marco@boeringa.demon.nl</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Thanks Peter,<br>
<br>
That certainly looks promising, and it is heartening to see real work <br>
already being done, although there appears to be no mention of Polygon <br>
type data being tested as well, but I don't know if geometry type is <br>
actually relevant to developing a faster GiST (spatial) index build. <br>
Probably not.<br>
<br>
10x improvement would be great... love to see that land in PostgreSQL 13!<br>
<br>
Marco<br>
<br>
Op 16-9-2020 om 22:13 schreef Peter Geoghegan:<br>
> On Wed, Sep 16, 2020 at 12:54 PM Marco Boeringa <<a href="mailto:marco@boeringa.demon.nl" target="_blank">marco@boeringa.demon.nl</a>> wrote:<br>
>> Appreciate your insights. Good to hear there appear to be opportunities<br>
>> for improvements to GiST index build speed in the future, even if no<br>
>> active work is being done right now. Yes, I do think a lot of people,<br>
>> and an increasing number, could benefit from such work. I personally<br>
>> would certainly applaud any improvements being made, as it is especially<br>
>> clear that disk speed is not an issue in most of the processing<br>
>> involved, and disk speed therefor unlikely to become limiting with any<br>
>> improvements in index creation, meaning there is likely a good<br>
>> opportunity for improving GiST index build speed.<br>
> Actually, there is ongoing work to speed up GiST index builds by using<br>
> Z-order + sorting:<br>
><br>
> <a href="https://postgr.es/m/123F5F32-9A85-4D0B-9C7A-1686E6BBE15D@yandex-team.ru" rel="noreferrer" target="_blank">https://postgr.es/m/123F5F32-9A85-4D0B-9C7A-1686E6BBE15D@yandex-team.ru</a><br>
><br>
> It reportedly can be as much as 10x faster. Building the index through<br>
> sorting rather than using retail inserts is inherently much faster.<br>
> And, we've put a lot of effort into speeding up B-Tree index<br>
> builds/sorting over several releases, to the point where a B-Tree<br>
> index build can be very I/O bound even on high end hardware. It seems<br>
> possible that GiST could get much of the benefit of that work by<br>
> adopting index builds to use Z-order.<br>
><br>
> The tricky part may be getting that benefit without significantly<br>
> impacting the final index structure. The idea of teaching GiST to<br>
> build indexes in a way that's a lot closer to B-Tree seems very<br>
> promising, though.<br>
><br>
_______________________________________________<br>
postgis-users mailing list<br>
<a href="mailto:postgis-users@lists.osgeo.org" target="_blank">postgis-users@lists.osgeo.org</a><br>
<a href="https://lists.osgeo.org/mailman/listinfo/postgis-users" rel="noreferrer" target="_blank">https://lists.osgeo.org/mailman/listinfo/postgis-users</a></blockquote></div>