Re: tuning questions

On Thu, 2003-12-04 at 11:20, Josh Berkus wrote:
> Jack,
>
> > Following this, I've done:
> > 2gb ram
> > =
> >  2,000,000,000
> > bytes
>
> This calculation is fun, but I really don't know where you got it from.   It
> seems quite baroque.  What are you trying to set, exactly?
Message-ID:  <3FCF6AEB.908@dsvr.net>
Date: Thu, 04 Dec 2003 17:12:11 +0000
From: Rob Fielding <rob@dsvr.net

I'm trying to set Postgres's shared memory usage in a fashion that
allows it to return requested results quickly. Unfortunately, none of
these changes allow PG to use more than a little under 300M RAM.
vacuumdb --analyze is now taking an inordinate amount of time as well
(40 minutes and counting), so that change needs to be rolled back.

>
> > getting the SQL query better optimized for PG is on my todo list, but
> > not something I can do right now -- this application is designed to be
> > cross-platform with MS-SQL, PG, and Oracle so tweaking SQL is a touchy
> > subject.
>
> Well, if you're queries are screwed up, no amount of .conf optimization is
> going to help you much.     You could criticize that PG is less adept than
> some other systems at re-writing "bad queries", and you would be correct.
> However, there's not much to do about that on existing systems.
>
> How about posting some sample code?

Tracking that down in CVS and translating from C++ is going to take a
while -- is there a way to get PG to log the queries it's receiving?

>
> > The pgavd conversation is intriguing, but I don't really understand the
> > role of vacuuming. Would this be a correct statement: "PG needs to
> > regularly re-evaluate the database in order to adjust itself?" I'm
> > imagining that it continues to treat the table as a small one until
> > vacuum informs it that the table is now large?
>
> Not Vacuum, Analyze.  Otherwise correct.  Mind you, in "regular use" where
> only a small % of the table changes per hour, periodic ANALYZE is fine.
> However, in "batch data transform" analyze statements need to be keyed to the
> updates and/or imports.
>
> BTW, I send a couple of e-mails to the Lyris documentation maintainer about
> updating out-of-date information about setting up PostgreSQL.   I never got a
> response, and I don't think my changes were made.

She sits on the other side of the cube wall from me, and if I find a
decent config it's going into the manual -- consider this a golden
opportunity :-)

--
Jack Coates, Lyris Technologies Applications Engineer
510-549-4350 x148, jack@lyris.com
"Interoperability is the keyword, uniformity is a dead end."
                --Olivier Fourdan