Re: postgresql.conf (Proposed settings)

From: mlw <markw(at)mohawksoft(dot)com>
To: PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: postgresql.conf (Proposed settings)
Date: 2001-11-20 18:16:01
Message-ID: 3BFA9DE1.76726080@mohawksoft.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers


Since I proposed three postgresql.conf configuration files, I will start by
suggesting some settings different from the default: (Any additions or corrections
would be greatly appreciated.)

Compact:
The current postgresql.conf

Workstation:
tcpip_socket = true
max_connections = 32
shared_buffers = 1024
sort_mem = 8192
random_page_cost = 2

Server:
tcpip_socket = true
max_connections = 128
shared_buffers = 8192
sort_mem = 16384
random_page_cost = 1

The random_page_cost is changed because of an assumption that the bigger systems
will be more busy. The more busy a machine is doing I/O the lower the differential
between a sequential and random access. ("sequential" to the application is less
likely sequential to the physical disk.)

I'd like to open a debate about the benefit/cost of shared_buffers. The question
is: "Will postgres' management of shared buffers out perform O/S cache? Is there a
point of diminishing return on number of buffers? If so, what?

Sort memory makes a huge impact on queries. If you got the memory, use it.

These are just ballpark settings, I don't even know how good they are. The problem
is that server environments differ so greatly that there is no right answer. I am
just really concerned that the newbe PostgreSQL user will assume the performance
they see with the default settings are what they will judge PostgreSQL.

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Hannu Krosing 2001-11-20 19:52:16 Re: OCTET_LENGTH is wrong
Previous Message Rene Pijlman 2001-11-20 18:05:41 Re: postgresql.conf