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 ---------------------------(end of broadcast)--------------------------- TIP 4: Don't 'kill -9' the postmaster
