Thread: Configurator project launched

Configurator project launched

From
Josh Berkus
Date:
Folks,

OK, I've checked in my first code module and the configurator project is
officially launched.  Come join us at
www.pgfoundry.org/projects/configurator

Further communications will be on the Configurator mailing list only.

from the spec:

What is the Configurator, and Why do We Need It?
-------------------------------------------------

The Configurator is a set of Perl scripts and modules which allow users and
installation programs to write a reasonable postgresql.conf for PostgreSQL
performance based on the answers to some relatively simple questions.  Its
purpose is to provide an option between the poor-performing default
configuration, and the in-depth knowledge required for hand-tuning.

--
--Josh

Josh Berkus
Aglio Database Solutions
San Francisco

Re: Configurator project launched

From
Josh Berkus
Date:
Greg,

> Not sure how far along you are, but I've been writing some really nifty
> extensions to DBD::Pg that allow easy querying of all the current
> run-time settings. Could be very useful to this project, seems to me. If
> you're interested in possibly using it, let me know, I can bump it up on
> my todo list.

Um, can't we just get that from pg_settings?

Anyway, I'll be deriving settings from the .conf file, since most of the
time the Configurator will be run on a new installation.

--
--Josh

Josh Berkus
Aglio Database Solutions
San Francisco

Re: Configurator project launched

From
"Joshua D. Drake"
Date:
Josh Berkus wrote:
> Greg,
>
>
>>Not sure how far along you are, but I've been writing some really nifty
>>extensions to DBD::Pg that allow easy querying of all the current
>>run-time settings. Could be very useful to this project, seems to me. If
>>you're interested in possibly using it, let me know, I can bump it up on
>>my todo list.
>
>
> Um, can't we just get that from pg_settings?
>
> Anyway, I'll be deriving settings from the .conf file, since most of the
> time the Configurator will be run on a new installation.

Aren't most of the settings all kept in the SHOW variables anyway?

Sincerely,

Joshua D. Drake


>


--
Your PostgreSQL solutions company - Command Prompt, Inc. 1.800.492.2240
PostgreSQL Replication, Consulting, Custom Programming, 24x7 support
Managed Services, Shared and Dedicated Hosting
Co-Authors: plPHP, plPerlNG - http://www.commandprompt.com/

Re: Configurator project launched

From
"Greg Sabino Mullane"
Date:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


>> Um, can't we just get that from pg_settings?
>>
>> Anyway, I'll be deriving settings from the .conf file, since most of the
>> time the Configurator will be run on a new installation.
>
> Aren't most of the settings all kept in the SHOW variables anyway?

As I said, it may not be applicable to this project, but thought I would
offer. One gotcha the module makes transparent is that in older versions of
PG, the variables are returned in a different way (via RAISE). My module
will allow you to get the configuration for any connected database, for
any configuration file, and the defaults for any known version, and do
quick comparisons between them all. So you could use it to see what has
changed between a particular server and its conf file, or the differences
between two conf files, or the differences between two databases, or even show
what has changed in the default conf file from 7.4.7 and 8.0.1. It will also
allow you to rewrite the conf files in a standard way.

I'm hoping to roll this into 1.44 or 1.45 or DBD::Pg.

- --
Greg Sabino Mullane greg@turnstep.com
PGP Key: 0x14964AC8 200506212046
http://biglumber.com/x/web?pk=2529DF6AB8F79407E94445B4BC9B906714964AC8
-----BEGIN PGP SIGNATURE-----

iD8DBQFCuLWDvJuQZxSWSsgRAjUVAJ42oeveZBuutFo1G3Cs/3dRZWjKggCfS1Yf
Tv5RWiG9s8Ucv/t/2HZ4/R8=
=1eap
-----END PGP SIGNATURE-----



Re: Configurator project launched

From
Andreas Pflug
Date:
Greg Sabino Mullane wrote:
>
>
>>>>Um, can't we just get that from pg_settings?
>>>>
>>>>Anyway, I'll be deriving settings from the .conf file, since most of the
>>>>time the Configurator will be run on a new installation.
>>>
>>>Aren't most of the settings all kept in the SHOW variables anyway?
>
>
> As I said, it may not be applicable to this project, but thought I would
> offer. One gotcha the module makes transparent is that in older versions of
> PG, the variables are returned in a different way (via RAISE). My module
> will allow you to get the configuration for any connected database, for
> any configuration file, and the defaults for any known version, and do
> quick comparisons between them all. So you could use it to see what has
> changed between a particular server and its conf file, or the differences
> between two conf files, or the differences between two databases, or even show
> what has changed in the default conf file from 7.4.7 and 8.0.1. It will also
> allow you to rewrite the conf files in a standard way.

Sounds a little similar to what's in pgAdmin CVS right now. The
configuration editor can retrieve the config file and display configured
and active setting concurrently, together with explanations taken from
pg_settings (when not run against a pgsql server but a file current
settings are missing, comments are taken from a pg_settings csv dump).
There's the infrastructure to give hints about all settings, with very
few currently implemented.

I wonder if this could be combined with the configurator somehow.
Currently, integration won't work with Perl, so maybe C for the core and
Perl for the interactive part would be better.

Regards,
Andreas

Re: Configurator project launched

From
"Greg Sabino Mullane"
Date:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


> Sounds a little similar to what's in pgAdmin CVS right now. The
> configuration editor can retrieve the config file and display configured
> and active setting concurrently, together with explanations taken from
> pg_settings (when not run against a pgsql server but a file current
> settings are missing, comments are taken from a pg_settings csv dump).
> There's the infrastructure to give hints about all settings, with very
> few currently implemented.
>
> I wonder if this could be combined with the configurator somehow.
> Currently, integration won't work with Perl, so maybe C for the core and
> Perl for the interactive part would be better.

Probably so. Seems there is a bit of convergent evolution going on. When I
get a moment of free time, I'll check out the pgAdmin code. Can someone
shoot me a URL to the files in question? (assuming a web cvs interface).

- --
Greg Sabino Mullane greg@turnstep.com
PGP Key: 0x14964AC8 200506242107
http://biglumber.com/x/web?pk=2529DF6AB8F79407E94445B4BC9B906714964AC8

-----BEGIN PGP SIGNATURE-----

iD8DBQFCvK6AvJuQZxSWSsgRApFcAKDVQ5OdVgVc2PmY/p719teJ3BqNjQCgrgyx
+w+w8GCGXUFO+5dxi5RPwKo=
=eG7M
-----END PGP SIGNATURE-----



Re: Configurator project launched

From
Andreas Pflug
Date:
Greg Sabino Mullane wrote:

>>I wonder if this could be combined with the configurator somehow.
>>Currently, integration won't work with Perl, so maybe C for the core and
>>Perl for the interactive part would be better.
>>
>>
>
>Probably so. Seems there is a bit of convergent evolution going on. When I
>get a moment of free time, I'll check out the pgAdmin code. Can someone
>shoot me a URL to the files in question? (assuming a web cvs interface).
>
>
>
http://svn.pgadmin.org/cgi-bin/viewcvs.cgi/trunk/pgadmin3/src/frm/frmMainConfig.cpp?rev=4317&view=markup

This is an editor only, an expert mode (e.g. recommendations for
different sizes/loads) would be nice.

Regards,
Andreas