Ever since I released explain.depesz.com over 11 years ago there have been cases were people would upload a plan and it didn't parse.
There were many reasons, but the most common was – plan was line-wrapped by injecting new-line characters where there shouldn't be one.
For example:
QUERY PLAN
──────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────
Sort (cost=32.88..32.96 ROWS=32 width=224) (actual TIME=0.532..0.532
ROWS=0 loops=1)
Sort KEY: n.nspname, c.relname
Sort Method: quicksort Memory: 25kB
-> Hash JOIN (cost=1.09..32.08 ROWS=32 width=224) (actual TIME=0.5
24..0.525 ROWS=0 loops=1)
Hash Cond: (c.relnamespace = n.oid)
-> Seq Scan ON pg_class c (cost=0.00..29.84 ROWS=64 width=73
) (actual TIME=0.026..0.397 ROWS=128 loops=1)
FILTER: ((relkind = ANY ('{r,p,v,m,S,f,""}'::"char"[])) AND pg_table_is_visible(oid))
ROWS Removed BY FILTER: 261
-> Hash (cost=1.07..1.07 ROWS=2 width=68) (actual TIME=0.062..0.062 ROWS=2 loops=1)
Buckets: 1024 Batches: 1 Memory Usage: 9kB
-> Seq Scan ON pg_namespace n (cost=0.00..1.07 ROWS=2 width=68) (actual TIME=0.032..0.038 ROWS=2 loops=1)
FILTER: ((nspname <> 'pg_catalog'::name) AND (nspname <> 'information_schema'::name) AND (nspname !~ '^pg_toast'::text))
ROWS Removed BY FILTER: 3
Planning TIME: 0.636 ms
Execution TIME: 0.616 ms
(15 ROWS)
This is artificial example, but it shows what is the problem. In case you don't see it – lines 4, 8, and 11 should be as continuation in previous lines.
Older Pg::Explain library when parsing such plans sometimes failed altogether, and sometimes produced incorrect results.
But today, I released new version that contains some support for unbreaking such plans. It doesn't work in all cases, and quite likely in most cases, but in some – it works.
Hope it will help you, and hope it doesn't break some pre-existing plans.