e finishes with 900M RSS.
After "ANALYZE old_prefs" the planner chooses GroupAggregate instead of
HashAggregate - you were right about missing statistics of old_prefs.
Thank you for figuring out this case
Best regards
--
luben karavelov
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
memory is not linear to work done - 2 transactions with 200k keys
will leak less than 1 transaction with 400k keys
Regarding Tom's question:
The old_prefs does not fit in work_mem but is quite small regarding the total
RAM. Isn't the "work_mem" a limit of the memory each backend could allocate for
sorting, grouping and aggregation? My understanding is that bigger allocation
will overflow to disk and will not kill the server. I could be wrong though.
Thanks in advance and best regards
--
Luben Karavelov
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
but
is quite small regarding the total RAM. Isn't the "work_mem" a limit of the
memory each backend could allocate for sorting, grouping and aggregation?
My understanding is that bigger allocation will overflow to disk and will
not kill the server. I could be wrong though. Thanks in advance and best
regards -- Luben Karavelov
The following bug has been logged on the website:
Bug reference: 6763
Logged by: Luben Karavelov
Email address: karave...@mail.bg
PostgreSQL version: 9.1.4
Operating system: Debian Linux
Description:
I was trying to migrate a big ER table (user preferences) into a
