Comment 17 for bug 1768022

That this is apparently limited to us is a good sign, I guess. The frustrating thing is that there doesn't appear to be anything I can do to knock that timing down. I've adjusted work_mem, join_collapse_limit, geqo_threshold, random_page_count, effective_cache_size, effective_io_concurrency, and temp_buffers to varying sizes from comically small to excessively large and it just won't budge. I haven't checked shared_buffers since the machine is in use and that one requires a restart, but I'll try that next.

If this type of bizarre planning top-heaviness is unique to us though this may as well be marked invalid.