Check out the ideas we noted on doing the same for geopoints: T320619: Investigate slow loading of complex SPARQL queries

If I can have some ideas on how many articles will gonna get bigger and how much, I can judge if it's going to break PC or not. Generally I support the idea though

In T322353#8382339, @Ladsgroup wrote:

If I can have some ideas on how many articles will gonna get bigger and how much, I can judge if it's going to break PC or not. Generally I support the idea though

In T322351: Investigation: Keep simplified geoshapes in maps database we found an average of 2.7kB for a sample of 1,500 geoshapes. Not many articles have maps (0.3% of enwiki pages and 10% of enwikivoyage), and many fewer of those include a geoshape. There's probably a long tail, a few articles might have 1 MB shapes for example. We can take a more careful survey as the proposal looks feasible.

Is it possible to generally pick a threshold below which we don't need to worry? Such as staying below a 1% bloat of parser cache...

Change 855984 had a related patch set uploaded (by Awight; author: Awight):

[mediawiki/extensions/Kartographer@master] [POC] Crude geoshape expansion

https://gerrit.wikimedia.org/r/855984

In T322353#8382381, @awight wrote:

In T322353#8382339, @Ladsgroup wrote:

If I can have some ideas on how many articles will gonna get bigger and how much, I can judge if it's going to break PC or not. Generally I support the idea though

In T322351: Investigation: Keep simplified geoshapes in maps database we found an average of 2.7kB for a sample of 1,500 geoshapes. Not many articles have maps (0.3% of enwiki pages and 10% of enwikivoyage), and many fewer of those include a geoshape. There's probably a long tail, a few articles might have 1 MB shapes for example. We can take a more careful survey as the proposal looks feasible.

Is it possible to generally pick a threshold below which we don't need to worry? Such as staying below a 1% bloat of parser cache...

With that numbers you can't get to 1% even if you try really hard. I think the change is fine and can go ahead from DBA point of view, just to be safe add a limit (maybe 1MB?) and if it's larger than that, trigger a statsd metric and avoid storing it for now. Then we can decide depending on the impact and so on what to do next.

In T322353#8391959, @Ladsgroup wrote:

just to be safe add a limit (maybe 1MB?) and if it's larger than that, trigger a statsd metric and avoid storing it for now

That's a great suggestion—and I should have added that this approach is quite easy, we can decide per-request if the expansion is possible or desirable, and fall back to the old data flow for that page by simply not expanding.