Re: Multiple Indexing, performance impact

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Daniel Åkerud <zilch(at)home(dot)se>
Cc: "PostgreSQL-general" <pgsql-general(at)postgresql(dot)org>
Subject: Re: Multiple Indexing, performance impact
Date: 2001-06-22 20:09:53
Message-ID: 5615.993240593@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general pgsql-hackers

=?iso-8859-1?Q?Daniel_=C5kerud?= <zilch(at)home(dot)se> writes:
> I did a ps ax | postmaster but found no -B, and concluded that it uses the
> value specified in /etc/postgrelsql/postgresql.conf on shared_buffers (I
> saw -B was shared buffer doing a man postmaster). I'll change this to 256
> and rerun the test!

> Will post the results here later. Please tell if this was a too puny
> increase!

That should be enough to see if there's a performance change, but for
future reference, yes you should go higher. On modern machines with
many megs of RAM, you should probably be using -B on the order of a few
thousand, at least for production installations. The reason the default
is so low is that we hope the system will still be able to fire up on
machines where the kernel enforces a SHMMAX limit of only a meg or so.
This hope is possibly in vain anymore anyway, since the system's
non-buffer shared-memory usage keeps creeping up; I think 7.1 is well
past 1MB shmem even with 64 buffers...

regards, tom lane

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message wsheldah 2001-06-22 20:22:07 Re: select to combine 2 tables
Previous Message Peter Eisentraut 2001-06-22 20:03:47 Re: TCP/IP Sockets, UNIX Sockets

Browse pgsql-hackers by date

  From Date Subject
Next Message Alex Pilosov 2001-06-22 20:44:46 plperl doc
Previous Message Tom Lane 2001-06-22 19:59:18 Re: Good name for new lock type for VACUUM?