Davin Potts <davin@xxxxxxxxxxxxxx> writes: > How to approach manipulating the execution plan back to something more > efficient? What characteristics of the table could have induced > analyze to suggest the much slower query plan? What's evidently happening is that the planner is backing off from using a hashed subplan because it thinks the hashtable will require more than work_mem. Is 646400 a reasonably good estimate of the number of rows that the sub-select will produce? If it's a large overestimate, then perhaps increasing the stats target for content.hash will help. If it's good, then what you want to do is increase work_mem to allow the planner to use the better plan. regards, tom lane -- Sent via pgsql-performance mailing list (pgsql-performance@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance
