Skip site navigation (1) Skip section navigation (2)

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 (view raw or flat)
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

pgsql-hackers by date

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

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group