Re: Optimization levels when compiling PostgreSQL...

Поиск
Список
Период
Сортировка
От Sean Chittenden
Тема Re: Optimization levels when compiling PostgreSQL...
Дата
Msg-id 20020910163043.GF26147@ninja1.internal
обсуждение исходный текст
Ответ на Re: Optimization levels when compiling PostgreSQL...  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
> > Don't doubt it at all, but that reminds me: I need to add a message
> > reminding the developer to re-initdb when installing this version.
> 
> The catversion check isn't good enough for you?

Nope, it's good enough and then some.  I've gotten in the habit of
just re-initdb'ing and figured that's what the rest of the world did:
didn't realize there was a way of testing the catalog versions.  My
life seems to be spent inside the DB and not playing with it from the
CLI.

> It seems you are busily reinventing a bunch of decisions that have
> already been made, and in most cases have stood the test of time.
> Perhaps you should be less eager to make this Sean's Own Postgres
> Version, and more eager to be pushing out something that matches
> what everyone else is testing.

Ouch!  I hope not.  Testing gcc optimizations and adding a developers
port of PostgreSQL hopefully isn't for just myself.

PostgreSQL has a chunk of work that needs to happen when setting it up
or upgrading and I am trying to smooth out as much of that as possible
such that installing PostgreSQL gets to the point of having it
reasonably tuned for the OS its being installed on after installing
the port.  Its not that install PostgreSQL is hard, far from, but
there's a reasonable checklist of things that needs to happen and that
requires a certain requisite knowledge of the database, tuning, and
the OS you're on: something, for better or worse, I assume most
users/DBA's don't have.  In a typical install, I generally do some
variation of the following:

*) setenv CFLAGS '-g -O3'
*) make
*) pg_dumpall > ~/db_dump
*) ${LOCALBASE}/etc/rc.d/010.pgsql.sh stop
*) make deinstall
*) make install
*) mv $PGDATA $PGDATA.old
*) initdb
*) diff -c $PGDATA.old/data/postgresql.conf $PGDATA/data/postgresql.conf > $PGDATA/data/postgresql.conf.patch
*) cd $PGSQL/data; patch -p0 < postgresql.conf.patch
*) edit postgresql.conf
*) ${LOCALBASE}/etc/rc.d/010.pgsql.sh start
*) psql -f ~/db_dump
*) vacuumdb -a -f -z
*) tweak various sysctl's to increase fd's, etc.
*) hopefully don't have to recompile the kernel with more shmem, etc

On some hosts, I've even got a script that I run that does all of that
for me because it's the exact same procedure every time.  :-/ Getting
as much of that done and taken care of as possible would probably be
appreciated and enjoyed by others.  It's not fool-proof, don't get me
wrong, but there's certainly some of that that can be automated, and
with tunables I'd like to for usabilities sake.

::shrug:: Usability's a touchy subject though and none of this will be
on by default so as to not offend the power-users out there.  -sc

-- 
Sean Chittenden


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: Optimization levels when compiling PostgreSQL...
Следующее
От: Barry Lind
Дата:
Сообщение: Re: [JDBC] problem with new autocommit config parameter