[Tile-serving] [openstreetmap/osm2pgsql] Enable lossy way-node indexes by default? (Issue #1687)

[Paul Norman]

So, I've been giving rendering server disk space a lot of thought for ops reasons.

- For a mixed-use dev server like I develop on, I'd rather have the extra disk space from lossy indexes, since update performance is not critical
- For a typical production rendering server with 256-512GB of RAM, I'd go with lossy indexes. A planet DB is about 1TB, and decreasing the size of the data needed for updates will keep more of the rendering working set in memory. If the server has much less RAM, it will be dependent on disk performance mainly, and if it has 1TB+ of RAM, it doesn't matter
- For a typical production on-demand rendering server with the DB and tiles on the same machine (i.e. the setup the OSMF runs), the metatile storage will consume all available disk space, and more space results in more cache hits. I would gladly take a 50% update CPU increase for 200GB more on a machine with only 3-4 TB of disk, because those stored tiles will reduce the time spent rendering, and significantly improve latency by avoiding rendering. So in this case I also want the lossy index.
- For a server with 7.68TB of NVMe or 1TB of RAM + 7.68TB of SATA SSDs, it doesn't matter.

So in all cases, I prefer lossy indexes or don't care which is used.

The only times I would force non-lossy indexes to be used is if had non-OSM data produced by a toolchain that produced IDs in a way that didn't have the same statistical properties as OSM IDs **and** cared about update latency with minutely or faster diffs.

-- 
Reply to this email directly or view it on GitHub:
https://github.com/openstreetmap/osm2pgsql/issues/1687#issuecomment-1204862078
You are receiving this because you are subscribed to this thread.

Message ID: <openstreetmap/osm2pgsql/issues/1687/1204862078 at github.com>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/tile-serving/attachments/20220804/e5c55486/attachment.htm>