[openstreetmap/openstreetmap-website] Idempotency for API 0.6 (#2201)

mmd notifications at github.com
Sat Apr 20 16:18:00 UTC 2019

@simonpoole : I don't know if you read my updated comment in https://github.com/openstreetmap/openstreetmap-website/issues/2201#issuecomment-484513542, if not, I'd recommend to take a look at it. There are indeed situations, in which an automated retry occurs without user intervention (no, I'm not talking about JOSM). So delegating the decision to the user may not really work out.

I don't want to bore folks here with lots of data, but in case you're still interested: I tried persisting a diffResult with 10k entries as JSONB. Saving the changeset took 2 seconds in total (that's on cgimap, not the Rails code that takes way longer). Out of those two seconds, saving the diffResult took 14 milliseconds. I used the SQL statement below to asses the size impact: it's at most 80k.

So the only remaining factors to asses the space requirements are now:

* how many changesets do we have in status "open" at any one time?
* what is the maximum number of changed objects in that timeframe? 

I guess the majority of changesets will have less than 500-700 changes - all of them fit on one page, and don't require and TOASTing.

SELECT *, pg_size_pretty(total_bytes) AS total
    , pg_size_pretty(index_bytes) AS INDEX
    , pg_size_pretty(toast_bytes) AS toast
    , pg_size_pretty(table_bytes) AS TABLE
  FROM (
( SELECT *, total_bytes-index_bytes-COALESCE(toast_bytes,0) AS table_bytes FROM (
      SELECT c.oid,nspname AS table_schema, relname AS TABLE_NAME
              , c.reltuples AS row_estimate
              , pg_total_relation_size(c.oid) AS total_bytes
              , pg_indexes_size(c.oid) AS index_bytes
              , pg_total_relation_size(reltoastrelid) AS toast_bytes
          FROM pg_class c
          LEFT JOIN pg_namespace n ON n.oid = c.relnamespace
          WHERE relkind = 'r'
  ) a
) a where table_name = 'changeset_idempotency_cache';

You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/rails-dev/attachments/20190420/b920de75/attachment-0001.html>

More information about the rails-dev mailing list