From: | Andrew Dunstan <andrew(at)dunslane(dot)net> |
---|---|
To: | Nick Eubank <nickeubank(at)gmail(dot)com> |
Cc: | pgsql-performance(at)postgresql(dot)org |
Subject: | Re: Tuning Postgres for Single connection use |
Date: | 2014-04-15 00:12:31 |
Message-ID: | 534C796F.7040904@dunslane.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
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
From | Date | Subject | |
---|---|---|---|
Next Message | Jeff Janes | 2014-04-15 00:19:22 | Re: Tuning Postgres for Single connection use |
Previous Message | Nick Eubank | 2014-04-14 23:39:26 | Re: Tuning Postgres for Single connection use |