Re: Auto-tuning work_mem and maintenance_work_mem - Mailing list pgsql-hackers

From Robert Haas
Subject Re: Auto-tuning work_mem and maintenance_work_mem
Date
Msg-id CA+TgmobtugZidHEaZJ7KFEnBsTHSaEV4Z0BKYB0bHyBL60dG4g@mail.gmail.com
Whole thread Raw
In response to Re: Auto-tuning work_mem and maintenance_work_mem  (Christopher Browne <cbbrowne@gmail.com>)
List pgsql-hackers
On Thu, Oct 10, 2013 at 3:41 PM, Christopher Browne <cbbrowne@gmail.com> wrote:
> On Thu, Oct 10, 2013 at 12:28 PM, Bruce Momjian <bruce@momjian.us> wrote:
>> How do we handle the Python dependency, or is this all to be done in
>> some other language?  I certainly am not ready to take on that job.
>
> I should think it possible to reimplement it in C.  It was considerably
> useful to start by implementing in Python, as that evades various sorts
> of efforts needed in C (e.g. - memory allocation, picking a hash table
> implementation), and allows someone to hack on it without needing to
> run through a recompile every time something is touched.

Also, the last time I saw that tool, it output recommendations for
work_mem that I would never, ever recommend to anyone on a production
server - they were VERY high.

More generally, Josh has made repeated comments that various proposed
value/formulas for work_mem are too low, but obviously the people who
suggested them didn't think so.  So I'm a bit concerned that we don't
all agree on what the end goal of this activity looks like.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company



pgsql-hackers by date:

Previous
From: Daniel Farina
Date:
Subject: Re: pg_stat_statements: calls under-estimation propagation
Next
From: Merlin Moncure
Date:
Subject: Re: dynamic shared memory: wherein I am punished for good intentions