Re: Multiple Indexing, performance impact
От | Lincoln Yeoh |
---|---|
Тема | Re: Multiple Indexing, performance impact |
Дата | |
Msg-id | 3.0.5.32.20010622121352.00866ba0@192.228.128.13 обсуждение исходный текст |
Ответ на | Re: [GENERAL] Multiple Indexing, performance impact (Bruce Momjian <pgman@candle.pha.pa.us>) |
Ответы |
Re: Multiple Indexing, performance impact
Re: [GENERAL] Re: Multiple Indexing, performance impact |
Список | pgsql-hackers |
At 05:56 PM 22-06-2001 -0400, Bruce Momjian wrote: >> Bruce Momjian <pgman@candle.pha.pa.us> writes: >> Since 64 is already too much to let 7.1 fit in SHMMAX = 1MB, I think >> the original rationale for using 64 is looking pretty broken anyway. >> Comments? > >BSD/OS has a 4MB max but we document how to increase it by recompiling >the kernel. Maybe if we fail the startup we can tell them how to >decrease the buffers in postgresql.conf file. Seems quite clear. > Why is SHMMAX so low on some O/Ses? What are the advantages? My guess is it's a minimum vs median/popular situation. Get the same thing looking at the default www.kernel.org linux kernel settings vs the Redhat kernel settings. I'd personally prefer the popular situation. But would that mean the minimum case can't even boot up to recompile? Maybe the BSD guys should ship with two kernels then. FreeBSD esp, since it's easy to recompile the kernel, just do two, during installation default to "Regular", with an option for "Tiny". It's more fair that the people trying the extraordinary (16MB 386) should be the ones doing the extra work. Cheerio, Link.
В списке pgsql-hackers по дате отправления: