Davin Potts <da...@appliomics.com> 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@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance
