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.