<!DOCTYPE html>
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<p>Thanks for pointing that out Imre!</p>
<p>That recent work on parallel GiST builds looks very promising,
and certainly the benchmarks are eyewatering. If this work makes
it into PG18, it will be a game changer for spatially indexing
OpenStreetMap Planet data, and make use of geography more
realistic with ultra large datasets. The postprocessing on
'planet_osm_polygon' of Daylight v1.55 took 24h33m with
'geography', while only 7h51m with 'geometry'. Both of these
timings will be slashed to usable proportions with parallel build.</p>
<p>Marco<br>
</p>
<div class="moz-cite-prefix">Op 2-11-2024 om 15:15 schreef Imre
Samu:<br>
</div>
<blockquote type="cite"
cite="mid:CAJnEWwkJR_XCXjZanY5DKqVcbip453DfbR0p1XOSoSNSD=QwcQ@mail.gmail.com">
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<div dir="ltr">
<div class="gmail_quote">
<blockquote class="gmail_quote"
style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<p>Just wondering, given the fact that, as it now turns out,
the specific step to calculate the bounding boxes is such
a large part of the overall time of the building of the
GiST spatial index, shouldn't this particular step be
parallelized in PostgreSQL via parallel workers?<br>
</p>
</blockquote>
<div><br>
</div>
<div>related: "WIP: parallel GiST index builds" ( first
mail: 2024-06-07 17:41:10 last mail: 2024-10-31 18:05:43
)<br>
<a
href="https://www.postgresql.org/message-id/flat/0e4f4af8-1088-4995-b2fb-8f92b5c6cef9%40enterprisedb.com"
moz-do-not-send="true" class="moz-txt-link-freetext">https://www.postgresql.org/message-id/flat/0e4f4af8-1088-4995-b2fb-8f92b5c6cef9%40enterprisedb.com</a></div>
<div><br>
</div>
<div>Imre<br>
</div>
</div>
</div>
</blockquote>
</body>
</html>