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?
Date: Thu, 04 Dec 2003 17:12:11 +0000
From: Rob Fielding <[EMAIL PROTECTED]

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, [EMAIL PROTECTED]
"Interoperability is the keyword, uniformity is a dead end."
                                --Olivier Fourdan

---------------------------(end of broadcast)---------------------------
TIP 4: Don't 'kill -9' the postmaster

Reply via email to