On Thu, Dec 9, 2010 at 5:25 AM, Paul Taylor <ijabz@xxxxxxxxxxx> wrote: > Hi, Im using Postgres 8.3 on a Macbook Pro Labtop. > I using the database with just one db connection to build a lucene search > index from some of the data, and Im trying to improve performance. The key > thing is that I'm only a single user but manipulating large amounts of data > , i.e processing tables with upto 10 million rows in them, so I think want > to configure Postgres so that it can create large temporary tables in memory > > I've tried changes various parameters such as shared_buffers, work_mem and > checkpoint_segments but I don't really understand what they values are, and > the documentation seems to be aimed towards configuring for multiple users, > and my changes make things worse. For example my machine has 2GB of memory > and I read if using as a dedicated server you should set shared memory to > 40% of total memory, but when I increase to more than 30MB Postgres will not > start complaining about my SHMMAX limit. So you're pretty much batch processing. Not Postgresql's strongest point. But we'll see what we can do. Large shared buffers aren't gonna help a lot here, since your OS will be caching files as well, and you've only got one process running. You do want a large enough shared_buffer to hold everything you're working on at one point in time, so getting it into the hundred or so megabyte range will likely help. After that you'll be stealing memory that could be used for OS caching or work_mem, so don't go crazy, especially on a machine with only 2 Gigs ram. Note I just picked up 8 gigs of DDR3 ram for $99 on newegg, so if you MBP can handle more memory, now's the time to splurge. Crank up work_mem to something pretty big, in the 60 to 200 meg range. note that work_mem is PER sort, not total or per connection. So if your single user runs a query with three sorts, it could use 3x work_mem. Once it allocates too much memory your machine will start swapping and slow to a crawl. So don't overshoot. Assuming you can recreate your db should things go horribly wrong, you can turn off fsync. Also crank up WAL segments to 32 or 64 or so. Make sure accesstime updates are turned off for the file system. (noatime mount option). -- To understand recursion, one must first understand recursion. -- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
