Re: using a lot of maintenance_work_mem

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Bruce Momjian <bruce(at)momjian(dot)us>
Cc: Devrim GÜNDÜZ <devrim(at)gunduz(dot)org>, Peter Eisentraut <peter_e(at)gmx(dot)net>, Frederik Ramm <frederik(at)remote(dot)org>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: using a lot of maintenance_work_mem
Date: 2011-02-20 21:31:06
Message-ID: 11323.1298237466@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Bruce Momjian <bruce(at)momjian(dot)us> writes:
> Tom Lane wrote:
>> You seem to be confusing one limitation in one code path with the
>> overall meaning of maintenance_work_mem.

> Oh, OK, so sorts are limited, but not hash sizes? Are there any other
> uses? Should this be documented somehow? What is the actual sort
> limit?

The particular complaint that's being made here is about tuplesort.c's
array of SortTuples, which isn't all (or even the largest part) of its
memory consumption. The tuples themselves eat significantly more in
nearly all cases. I don't think there's any very easy way to document
what the largest useful maintenance_work_mem for sorting is based on
that --- you'd have to pull a number for tuple size out of the air.
But it's certainly possible to use up lots of gigabytes when sorting
wide tuples. I think the original complaint in this thread was about
building an index, which probably had relatively small tuples so the
SortTuple constraint was more pressing.

In any case, this is the sort of thing that'd be far better to fix than
document.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2011-02-20 22:38:13 Re: review: FDW API
Previous Message Bruce Momjian 2011-02-20 21:09:11 Re: using a lot of maintenance_work_mem