Tom Lane [EMAIL PROTECTED] writes:
It'd be nice to get out from under the fixed-size-shmem restriction, but
I don't know any very portable way to do that.
Without knowing that part of the code at all it seems to me the logical
approach would be to make the fsm steal its pages out of the
Tom Lane wrote:
The thought behind my suggestion was that the current max_fsm_pages
default of 2 pages is enough to track free space in a database of
maybe a few hundred megabytes. The other defaults are sized
appropriately for machines with about that much in main memory. This
doesn't
On Sun, Sep 11, 2005 at 12:15:01PM -0400, Greg Stark wrote:
It'd be nice to get out from under the fixed-size-shmem restriction, but
I don't know any very portable way to do that.
Without knowing that part of the code at all it seems to me the logical
approach would be to make the fsm
On Thursday 08 September 2005 13:16, Andrew Dunstan wrote:
Initdb already
has adaptive rules - look at the source - and Tom suggests adding
another set for max_fsm_pages. All I'm doing is to suggest that we need
to tweak those.
I'm curious how this could work... istm its fairly hard to
Robert Treat [EMAIL PROTECTED] writes:
On Thursday 08 September 2005 13:16, Andrew Dunstan wrote:
Initdb already
has adaptive rules - look at the source - and Tom suggests adding
another set for max_fsm_pages. All I'm doing is to suggest that we need
to tweak those.
I'm curious how this
Andrew Dunstan wrote:
And anyway you need to come up with a reasonable alternative for
packagers, rather than just say don't do this.. The only one I can
think of is to run initdb as part of a package postinstall, although
packagers and especially distro preparers might find that more than
On 2005-09-08, Peter Eisentraut [EMAIL PROTECTED] wrote:
Andrew - Supernews wrote:
On 2005-09-08, Peter Eisentraut [EMAIL PROTECTED] wrote:
Andrew - Supernews wrote:
Running initdb behind the scenes is a proven dangerous practice
Please elaborate.
Example instance:
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
Andrew - Supernews
Sent: 09 September 2005 08:16
To: pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] initdb profiles
On 2005-09-08, Peter Eisentraut [EMAIL PROTECTED] wrote:
Andrew
Dave Page wrote:
perhaps your statement would be more
accurate as:
Automatically running initdb behind the scenes at system startup is a
proven dangerous practice
We've distributed hundreds of thousands of copies of pgInstaller which
initdb's behind the scenes and never had any reported
On Thu, Sep 08, 2005 at 08:29:38PM -, Andrew - Supernews wrote:
On 2005-09-08, Peter Eisentraut [EMAIL PROTECTED] wrote:
Andrew - Supernews wrote:
Running initdb behind the scenes is a proven dangerous practice
Please elaborate.
Example instance:
On Thu, Sep 08, 2005 at 03:43:17AM +0200, Peter Eisentraut wrote:
What I would like to see is that initdb would end with saying that the
system is not really tuned and that I should run pg-some-program to
improve that. pg-some-program would analyze my system, ask me a few
questions, and
Jim C. Nasby wrote:
On Thu, Sep 08, 2005 at 03:43:17AM +0200, Peter Eisentraut wrote:
What I would like to see is that initdb would end with saying that the
system is not really tuned and that I should run pg-some-program to
improve that. pg-some-program would analyze my system, ask me
Hello All,
Please allow me to put a disclaimer, I am no serious PG hacker,
but would it be possible to allow for a simple config script to be run
(which would work even via /etc/init.d) which could be used to generate a
config file for initdb, which initdb could read and do its thing ?
On Thu, Sep 08, 2005 at 09:54:59AM +0800, Christopher Kings-Lynne wrote:
I think we should just do what MySQL does and include:
postgresql.conf
postgresql-large.conf
postgresql-huge.conf
I do that, in the package of PG I distribute with my application. I
tell the user that they should use
Steve Atkins wrote:
These are technically literate customers working for large ISPs, with
significant local sysadmin and DBA support, so the concept is not beyond them.
Yet when I ssh in to one of their servers only about 1 in 3 is running
with anything other than the default
On 2005-09-08, Tom Lane [EMAIL PROTECTED] wrote:
initdb is really the wrong place for this anyway, because in many
situations (RPM installations for instance) initdb is run behind the
scenes with no opportunity for user interaction. We should be doing
our best to remove options from initdb,
Folks,
Help on the Configurator is actively solicited. I really think this is a
better solution for this problem.
http://www.pgfoundry.org/projects/configurator
--
Josh Berkus
Aglio Database Solutions
San Francisco
---(end of broadcast)---
TIP
Josh Berkus wrote:
Folks,
Help on the Configurator is actively solicited. I really think this is a
better solution for this problem.
http://www.pgfoundry.org/projects/configurator
I don't agree, for several reasons.
1. Steve has already told us most of his clients just go with the
Andrew - Supernews wrote:
Running initdb behind the scenes is a proven dangerous practice
Please elaborate.
--
Peter Eisentraut
http://developer.postgresql.org/~petere/
---(end of broadcast)---
TIP 4: Have you searched our list archives?
Andrew - Supernews [EMAIL PROTECTED] writes:
On 2005-09-08, Tom Lane [EMAIL PROTECTED] wrote:
initdb is really the wrong place for this anyway, because in many
situations (RPM installations for instance) initdb is run behind the
scenes with no opportunity for user interaction. We should be
Andrew Dunstan wrote:
I have a single instance of apache running on this machine. It's not
doing anything, but even so it's consuming 20% of physical memory. By
contrast, my 3 postmasters are each consuming 0.5% of memory. All
If I see this right, my Apache, running at default settings, uses
Christian,
Regarding Configurator, has anything been done yet, or is it in the
planning stage?
Yes, I have a spreadsheet mapping the values we want to configure for 8.0.
Dave Cramer has done a partial implementation in Java using Drools; the
perl implementation is lagging rather further
On 2005-09-08, Peter Eisentraut [EMAIL PROTECTED] wrote:
Andrew - Supernews wrote:
Running initdb behind the scenes is a proven dangerous practice
Please elaborate.
Example instance:
http://archives.postgresql.org/pgsql-hackers/2004-12/msg00851.php
More generally, you risk running initdb and
Andrew - Supernews wrote:
On 2005-09-08, Peter Eisentraut [EMAIL PROTECTED] wrote:
Andrew - Supernews wrote:
Running initdb behind the scenes is a proven dangerous practice
Please elaborate.
Example instance:
http://archives.postgresql.org/pgsql-hackers/2004-12/msg00851.php
If you run
One regular topic of conversation on IRC and elsewhere is that the
settings initdb installs especially for memory use, connections, and so
on, are often very conservative. Of course, we tell people how to tune
them to some extent, although performance tuning seems to remain a black
art. But
Andrew Dunstan wrote:
But I wondered if it might not be a good idea to allow
an option to initdb which would provide a greater possible range of
settings for max_connections, shared_buffers and so on. For example,
we might offer a profile which is very conservative for memory bound
That
Peter Eisentraut [EMAIL PROTECTED] writes:
All jokes aside, tuning aids are surely needed, but letting initdb guess
the required profile isn't going to do it.
initdb is really the wrong place for this anyway, because in many
situations (RPM installations for instance) initdb is run behind the
Andrew Dunstan wrote:
The idea was in fact to allow the user to provide additional
information to allow initdb to make better guesses than it currently
does.
There's certainly going to be opposition to making initdb an interactive
tool.
The other problem is that no one has ever managed to
What I would like to see is that initdb would end with saying that the
system is not really tuned and that I should run pg-some-program to
improve that. pg-some-program would analyze my system, ask me a few
questions, and then output a suggested configuration (or apply it right
away).
Joshua D. Drake [EMAIL PROTECTED] writes:
What I would like to see is that initdb would end with saying that the
system is not really tuned and that I should run pg-some-program to
improve that.
Perhaps at the end of initdb it would say would you like
to run the PostgreSQL configuration
Tom Lane wrote:
Andrew Dunstan [EMAIL PROTECTED] writes:
I accept the run from init.d argument. So then, is there a case for
increasing the limits that initdb works with, to reflect the steep rise
we have seen in typically available memory at the low end?
I can't see any
Peter Eisentraut [EMAIL PROTECTED] writes:
There is a compromise that I think we cannot make. For production
deployment, shared buffers are typically sized at about 10% to 25% of
available phyiscal memory. I don't think we want to have a default
installation of PostgreSQL that takes 10%
Peter Eisentraut wrote:
Andrew Dunstan wrote:
I accept the run from init.d argument. So then, is there a case for
increasing the limits that initdb works with, to reflect the steep
rise we have seen in typically available memory at the low end?
There is a compromise that I think we
heuristics that initdb could apply. We'd have to let all of these
degrade nicely, so that even if the user select the machine hog setting,
if we find we can only do something like the tiny setting that's what
s/he would get. Also, we might need to have some tolerably portable way
of finding
34 matches
Mail list logo
