The planner is not aware of what else is going on in the server
I was not aware of this as well.
I'd guess that the 2nd database is missing the geometry index, or has it defined in some different way such that the database doesn't think it can be used.
Unfortunately - no. E.g. the first problematic plan I posted is from the same schema loaded with the same data as the one that works well. All tables are generated freshly from scratch by the same script only minutes before this query is run. I tested them all individually and never saw any problem, all use the same plan. As soon as I run two in parallel it happens. I also did a test by feeding two tables with identical data - again the same problem.
First I used tables in different schemas, then I tested to run them in different databases. It had no influence. The thing is 100% reproducable on three different machines with different hardware, different OS and different pgsql versions. A single query is fast, as soon as a second one comes in parallel it gets stuck. Every other query I have in the toolchain does not show this behavior - and there are some quite expensive ones as well.
I think what I would do next is EXPLAIN (without ANALYZE) one of the queries repeatedly, say once a second, while the other query either runs or doesn't run repeatedly, that is the other query runs for 11 minutes (or however it takes to run), and then sleeps for 11 minutes in a loop. Then you can see if the explain plan differs very reliably, and if the transition is exactly aligned with the other starting and stopping or if it is offset.
