Or we could switch to a more compact representation of the dead tuples,
and not need such a big maintenance_work_mem in the first place.
Jim C. Nasby wrote:
> On Fri, May 11, 2007 at 10:18:30PM -0400, Robert Treat wrote:
>> On Wednesday 09 May 2007 19:41, Guillaume Smet wrote:
>>> On 5/9/07, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>>>> Jim Nasby <decibel@decibel.org> writes:
>>>>> Any time this happens it's generally a nasty surprise for users.
>>>> Really? Running out of work memory is expected on large tables.
>>> Sure. Perhaps we should find a better error message but it's an
>>> interesting information. Personnaly, I try to choose a sane value
>>> depending on my database but I'm never sure it's really sufficient or
>>> if I added 100MB it would have made a real difference.
>
> Unfortunately, a lot of users aren't as knowledgeable as folks here,
> that's why I made it a warning and gave it a hint. But if people think
> that's too high a level we can change it to something lower...
>
>> If we were going to implement this (and I'm a tad skeptical as well), wouldn't
>> it be better if the warning occured at the end of vacuum, and told you how
>> much memory was actually needed, so you'd know what maintainence_work_mem
>> should be.
>
> Maybe... the problem is that for really large tables you simply won't
> have a choice; it will have to fall to disk. So I think we'd have to
> keep per-table warnings, unless you've got an idea for how we could
> account for tables that wouldn't reasonably fit?
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
