Thank you for the clear explanation, and I hope the missing optimisation gets implemented sooner rather than later. Maybe the query planner should consider the missing optimisation and ban *hash* partitionwise joins. Indeed I verified that disabling hash join fixed the situation, with both queries taking almost the same time. Great! In the meantime, I'm considering disabling hash joins globally, as I've had issues with them before (excessive I/O slowing causing much slower execution than merge join, see [1] for your answer to my question then :). Do you think that would save me from other problems I'm not aware of, given the huge size of the table I'm querying? [1] https://www.postgresql.org/message-id/CAApHDvpPVydoNkEqLyBSbjWq8kq8M7YWdkA44rTeA2MNaO3jsw@xxxxxxxxxxxxxx Regards, Dimitris
