Re: problem with large maintenance_work_mem settings and

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Simon Riggs <simon(at)2ndquadrant(dot)com>
Cc: pgsql-hackers(at)postgresql(dot)org, Stefan Kaltenbrunner <stefan(at)kaltenbrunner(dot)cc>
Subject: Re: problem with large maintenance_work_mem settings and
Date: 2006-03-10 15:00:55
Message-ID: 5261.1142002855@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Simon Riggs <simon(at)2ndquadrant(dot)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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Simon Riggs 2006-03-10 15:41:28 Re: [HACKERS] Automatic free space map filling
Previous Message Jan Wieck 2006-03-10 14:53:31 Re: [COMMITTERS] pgsql: Remove Christof Petig copyright on include