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
