David,
> It would be good to narrow down which plan node is causing this. Can
> you try disabling various planner enable_* GUCs before running EXPLAIN
> (SUMMARY ON) <your query> with \timing on and see if you can find
> which enable_* GUC causes the EXPLAIN to run more quickly? Just watch
> out for variations in the timing of "Planning Time:". You're still
> looking for a large portion of time not accounted for by planning
> time.
I put the original values for work_mem and temp_buffers back to 1GB
(don't know if that made a difference in the results).
Execution time is consistent at ~135ms
Here are the results for planning time, disabling each planner method :
enable_async_append 0.454ms *slowest
enable_bitmapscan 0.221ms
enable_gathermerge 0.176ms
enable_hashagg 0.229ms
enable_hashjoin 0.127ms
enable_incremental_sort 0.143ms
enable_indexonlyscan 0.147ms
enable_indexscan 0.200ms
enable_material 0.138ms
enable_memoize 0.152ms
enable_mergejoin 0.122ms*fastest
enable_nestloop 0.136ms
enable_parallel_append 0.147ms
enable_parallel_hash 0.245ms
enable_partition_pruning 0.162ms
enable_seqscan 0.137ms
enable_sort 0.143ms
enable_tidscan 0.164ms
Hope this helps.
Thanks,
JC