What is this Greg?
""""""""""""""""""""""

Well, I've always been fascinated with genetic algorithms. Having solved one problem in the past using the genetic algorithm of a kind (don’t ask me about the exact name) – I wanted to try applying it to a different kind of issue. 
Basically – whenever you have an issue that can be solved in many ways, with multi dimensional solution space – genetic algorithms become useful. This is even more so when the number of dimensions increases and ability to test all possible solutions is not possible. Well – sounds like something you can apply to systems with many configuration options. So I thought, well – lets see what can we do here with PostgreSQL. 

Mind you, this is a very simple project – if not just a proof of concept. I’m currently in the middle of testing it on few different machines. 

It’s written in Python 2.7. I tested it on Mac OSX 10.8. But I’m sure it will work on Linux too (I don’t do anything OSX specific here).


What's in here?
""""""""""""""""""""""
The project currently comprises of two python files:
•	postgres_config.py – implements PostgreSQL configuration actions. Such as, generate random configuration file, run cross over ‘mating’, print or save configuration file, etc.;
•	gs.py – main file. Runs the actual genetic algorithm, implements bits of it in rather loose fashion. This should ideally be split into separate class that would be agnostic to the type of configuration or problem it tries to ran.


And few shell files:
•	setup_test_env.sh – sets up PostgreSQL as your current user. Do not run it as root!! Besides being bonkers way of doing things, it is rather dangerous! It will set up your PostgreSQL instance in /tmp/pgbench. Again, something that should be configurable
•	reload_postgresql_with_new_config.sh – Used by the python script, takes single parameter. The parameter being the configuration file.  It will stop current instance, replaces postgresql.conf with the file supplied and starts up new PostgreSQL instance again. Paths are hardcoded (bad).
•	run_a_test.sh – As the name suggests, is used by the python process to perform single test. Runs pgbench tests (write and select test). Each test is suppose to run for 15s (configurable of course). Echoes out the result  – which is then used by the python process as score. If failed, 0 is echoed






How do I use it Greg?
"""""""""""""""""""""""
All scripts assume PostgreSQL is installed in /usr/local/pgsql . That’s where I have it – change paths if you want. They are unfortunately hardcoded at the moment.

Again, this whole thing is rather basic – and still needs a lot of work (like any proof of concept). Don’t expect it to function without any tweaks in configuration. To adopt it to your needs, you should at least create new test script that implements your specific characterisation suite. 

To run it:
•	make sure your postgresql is installed in /usr/local/pgsql
•	don’t be root ;{)
•	run ./ setup_test_env.sh
•	run python gs.py

Leave it running for few days. Collect results from population_[n].ppldump files. It will include all configuration bits and the result. Currently there’s no general goal (just like in nature) this has to achieve to stop. So it will be running 1000 (hardcoded) populations and then it will stop (that would take a while, so …). In my experience it takes about 45 minutes to an hour to run one population, more or less. 
Of course changing number of chromosomes in population, and changing the test script will alter that number.


What's next Greg?
""""""""""""""""""""""
If you want to tell me how bad this is, and how wrong I am – don’t.
Any positive comments, patches, creative ideas - please email me.
Money or job offers (I'm a freelancer) - contact me too please!