Re: problem with large maintenance_work_mem settings and - Mailing list pgsql-hackers

From Tom Lane
Subject Re: problem with large maintenance_work_mem settings and
Date
Msg-id 5261.1142002855@sss.pgh.pa.us
Whole thread Raw
In response to problem with large maintenance_work_mem settings and CREATE INDEX  (Stefan Kaltenbrunner <stefan@kaltenbrunner.cc>)
List pgsql-hackers
Simon Riggs <simon@2ndquadrant.com> writes:
> On Fri, 2006-03-10 at 09:31 -0500, Tom Lane wrote:
>> I'll look into it, but I was already wondering if we shouldn't bound the
>> number of tapes somehow.  It's a bit hard to believe that 28000 tapes is
>> a sane setting.

> I thought you had changed the memory settings so that the 28658 was a
> maximum, not the actual number it used.

Well, it does set up the control structures with 28658 entries, but the
I/O buffers and so on are not allocated unless used (in this instance
only two will get used).  logtape.c itself does not look like it has any
serious problem with too many tapes, but maybe tuplesort.c does.  Or the
problem Stefan has stumbled across might be unrelated to number of
tapes, anyway --- we still need to dig.

> Seems reasonable to limit tapes to say 10,000. 28000 tapes allows you to
> sort 448 TB without any merging...

Yeah, I was thinking MAXTAPES = 10000 might not be a bad idea.
        regards, tom lane


pgsql-hackers by date:

Previous
From: Simon Riggs
Date:
Subject: Re: problem with large maintenance_work_mem settings and
Next
From: Jan Wieck
Date:
Subject: Re: [COMMITTERS] pgsql: Remove Christof Petig copyright on include