Re: problem with large maintenance_work_mem settings and

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: problem with large maintenance_work_mem settings and
Дата
Msg-id 5261.1142002855@sss.pgh.pa.us
обсуждение исходный текст
Ответ на problem with large maintenance_work_mem settings and CREATE INDEX  (Stefan Kaltenbrunner <stefan@kaltenbrunner.cc>)
Список 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 по дате отправления:

Предыдущее
От: Simon Riggs
Дата:
Сообщение: Re: problem with large maintenance_work_mem settings and
Следующее
От: Jan Wieck
Дата:
Сообщение: Re: [COMMITTERS] pgsql: Remove Christof Petig copyright on include