What can cause low cost and high runtime in EXPLAIN ANALYZE?
My first thought is that some other activity is bogging down postgres causing this


My first thought is the data is better or worse cached than the assumptions which are implicitly baked into the random_page_cost / seq_page_cost ratio(and into some various other things).  My second thought is that the expected number of rows is very wrong (compared to the actual number of rows reported by EXPLAIN ANALYZE) and that that leads to wrong costs.  Sometimes those thought orders are reversed.

But I also always keep a terminal open running 'top', so if I am running a query in real time (as opposed to finding it in the slow query log) I can immediately rule out the idea that other work is slowing things down.


  Am I mistaken to expect similar cost:time ratios for different queries?


While that is clearly the goal (what is the point of assigning costs to alternatives and choosing the lowest cost plan if has no better than random chance of actually being faster than a higher cost plan?), planning is very difficult and you shouldn't expect the correlation to be all that tight.

If you are one of the "hackers" who writes the code behind PostgreSQL and you want to find weaknesses in the planner for future improvement, then it might make sense to develop sense of the typical ratio between "arbitrary cost units" and ms of execution time.  But you have to carefully control for how hot the cache is for this to have even a snowball's chance of working.