"Mark Woodward" <pgsql@mohawksoft.com> writes:
> -> HashAggregate (cost=106527.68..106528.68 rows=200 width=32)
> Filter: (count(ucode) > 1)
> -> Seq Scan on cdtitles (cost=0.00..96888.12 rows=1927912
> width=32)
> Well, shouldn't hash aggregate respect work memory limits?
If the planner thought there were 1.7M distinct values, it wouldn't have
used hash aggregate ... but it only thinks there are 200, which IIRC is
the default assumption. Have you ANALYZEd this table lately?
Meanwhile, I'd strongly recommend turning off OOM kill. That's got to
be the single worst design decision in the entire Linux kernel.
regards, tom lane
