Carlo Stonebanks wrote: > A client is moving their postgresql db to a brand new Windows 2003 x64 > server with 2 quad cores and 32GB of RAM. It is a dedicated server to run > 8.2.4. Large shared_buffers and Windows do not mix. Perhaps you should leave the shmem config low, so that the kernel can cache the file pages. > The server typically will have less than 10 users. The primary use of this > server is to host a database that is continuously being updated by data > consolidation and matching software software that hits the server very > hard. There are typically eight such processes running at any one time. The > software extensively exploits postgresql native fuzzy string for data > matching. The SQL is dynamically generated by the software and consists of > large, complex joins. (the structure of the joins change as the software > adapts its matching strategies). It sounds like you will need a huge lot of vacuuming effort to keep up. Maybe you should lower autovac scale factors so that your tables are visited more frequently. A vacuum_delay of 40 sounds like too much though. Since you didn't describe your disk configuration, it is most likely not really prepared to handle high I/O load. Maybe you should fix that. -- Alvaro Herrera http://www.CommandPrompt.com/ PostgreSQL Replication, Consulting, Custom Development, 24x7 support ---------------------------(end of broadcast)--------------------------- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
