Auto-tuning GUCS

From: "Michael Nacos" <m(dot)nacos(at)gmail(dot)com>
To: "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: "Gregory Stark" <stark(at)enterprisedb(dot)com>, "Greg Smith" <gsmith(at)gregsmith(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Auto-tuning GUCS
Date: 2008-08-19 09:16:20
Message-ID: 407fa4640808190216i1ec20c0ax1bda8879b46f86aa@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

> > I do think you and others make it less likely every time you throw up big
> > insoluble problems like above though. As a consequence every proposal has
> > started with big overly-complex solutions trying to solve all these
> incidental
> > issues which never go anywhere instead of simple solutions which directly
> > tackle the main problem.
>

insoluble? overly-complex solution? parsing a text file? I do not think we
understand
each other, or rather we start with totally different assumptions and design
goals.
it was probably a mistake to post keeping the subject line as it is,
considering I have
no interest overhauling GUCS, but this is where the subject of autotuning
was brought
up and this is where I posted.

now, to me, shell access, cron jobs, text config files - or rather, a single
text config
file, these are all good. if you plan to deploy/maintain entire farms or
cloud solutions,
tough! you should be looking into configuration management, such as cfengine
and
puppet already!

you seem to consider ease of use a prerequisite for tuning efficiency, our
design goals
couldn't be more different. what you want is an installer - what I'd like is
DBA support

>Coping with user and system-generated comments is one difficult part that
people
>normally don't consider, dealing with bad settings the server won't start
with is another.

now, as things stand, I will tinker in this area, simply because I'm
stubborn and this is
part of my job. I have parsed many text files in my professional career,
please do not
think a simple config file should be a problem (even with comments, I think)

The impression I get every time this comes up is that various people
> have different problems they want to solve that (they think) require
> redesign of the way GUC works. Those complicated solutions arise from
> attempting to satisfy N different demands simultaneously. The fact that
> many of these goals aren't subscribed to by the whole community to begin
> with doesn't help to ease resolution of the issues.
>

in this single thread I have identified at least three different development
targets:

* newbie-friendly default-guessing installer
* configuration manager for farms/clouds etc.
* auto-tuning support

this is why I'm posting this with a different subject line. If anyone wants
to discuss the
GUCS auto-tuning part, I'm all ears.

regards,

Michael

Browse pgsql-hackers by date

  From Date Subject
Next Message Pavel Stehule 2008-08-19 09:24:24 Re: possible minor EXPLAIN bug?
Previous Message Peter Eisentraut 2008-08-19 09:14:47 Re: Overhauling GUCS