On 04/14/2014 05:46 PM, Nick Eubank wrote:
Any rules of thumb for |work_mem|, |maintenance_work_mem|,
|shared_buffer|, etc. for a database that DOESN'T anticipate
concurrent connections and that is doing lots of aggregate functions
on large tables? All the advice I can find online on tuning (this
<http://wiki.postgresql.org/wiki/Performance_Optimization>, this
<http://media.revsys.com/talks/djangocon/2011/secrets-of-postgresql-performance.pdf>,
this
<http://www.revsys.com/writings/postgresql-performance.html> etc.) is
written for people anticipating lots of concurrent connections.
I'm a social scientist looking to use Postgres not as a database to be
shared by multiple users, but rather as my own tool for manipulating a
massive data set (I have 5 billion transaction records (600gb in csv)
and want to pull out unique user pairs, estimate aggregates for
individual users, etc.). This also means almost no writing, except to
creation of new tables based on selections from the main table.
I'm on a Windows 8 VM with 16gb ram, SCSI VMware HD, and 3 cores if
that's important.
First up would probably be "don't run on Windows". shared_buffers above
512Mb causes performance to degrade on Windows, while that threshold is
much higher on *nix.
cheers
andrew
--
Sent via pgsql-performance mailing list (pgsql-performance@xxxxxxxxxxxxxx)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance
