Greg Smith wrote:
While I've got a pretty clear vision for what I'm doing with this next
and will kick off a pgfoundry project real soon, I wanted to throw
this out as a WIP for feedback at this point. I was ultimately hoping
to one day have something like this shipped as a contrib/ module to
address the constant requests for such a thing. I know it would be
unreasonable to expect something in this state to make it into the 8.4
contrib at this late hour. But since it's independant of the core
database stuff I figured I'd make it available right at the wire here
today in the off chance that did seem a reasonable proposition to
anybody. It is already a big improvement over no tuning at all, and
since it's a simple to change script I will rev this based on feedback
pretty fast now that the most boring guts are done.
I've picked this up to look at it. Will give feedback once I have a
python installed.
-Setting the next round of values requires asking the user for some
input before making recommendations. Is it worth building a
curses-based interface to updating the values? That would be really
helpful for people with only ssh access to their server, but barring
something like WCurses I'm not sure it would help on Windows.
I'd start with command-line switches, e.g.
config --memory=32GB --type=DW --size=500GB --connections=20
-I'm not sure if there's any useful replacement for the os.sysconf
interface I'm using to grab the memory information on the popular
Windows Python ports. Some of the other projects I looked at that
tried to abstract that OS interaction more didn't seem much better
here (i.e. the PSI library which doesn't support Windows either)
I think in initial versions we should just get the info from the admin.
I've explored the issues around getting OS-independant accurate system
stats, and they are many.
-Stepping back a bit from this particular code, is something in Python
like this ever going to be appropriate to ship as a contrib module?
There seems to be a bit more traction in this community for using Perl
for such things; I might do a Perl port of this one day but that's not
going to happen soon.
If you do a python version, others will write versions in other
languages. I personally don't really care; Perl's main advantage is
that it's pre-installed on more OSes than Python is.
Anyway, more feedback once I get it running.
--Josh
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
