Re: tuning questions

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?

> 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?

> 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.

--
-Josh Berkus
 Aglio Database Solutions
 San Francisco