Re: Multiple Indexing, performance impact

From: Lincoln Yeoh <lyeoh(at)pop(dot)jaring(dot)my>
To: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Daniel Åkerud <zilch(at)home(dot)se>, PostgreSQL-general <pgsql-general(at)postgresql(dot)org>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Multiple Indexing, performance impact
Date: 2001-06-22 04:13:52
Message-ID: 3.0.5.32.20010622121352.00866ba0@192.228.128.13
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general pgsql-hackers

At 05:56 PM 22-06-2001 -0400, Bruce Momjian wrote:
>> Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)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.

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message will trillich 2001-06-22 04:15:31 where's the reference to a view, here?
Previous Message Paul Mamin 2001-06-22 04:10:26 Re[2]: Postgres is too slow?

Browse pgsql-hackers by date

  From Date Subject
Next Message Alex Pilosov 2001-06-22 04:33:19 SPI_prepare for semi-unknown types
Previous Message AV 2001-06-22 03:52:50 Re: JDBC Connection State Management with SQL Exceptions (esp Postgresql)