From: | Square Bob <square_bob(at)yahoo(dot)com> |
---|---|
To: | pgsql-performance(at)lists(dot)postgresql(dot)org |
Subject: | Re: amazon aroura config - seriously overcommited defaults? (May be Off Topic) |
Date: | 2018-12-09 15:20:51 |
Message-ID: | 84bcf9cf-f6b6-41ab-3e67-cdd149dc7331@yahoo.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general pgsql-performance |
On 12/9/18 5:51 AM, Andrew Dunstan wrote:
>
> On 12/8/18 6:38 PM, Andres Freund wrote:
>> On 2018-12-08 15:23:19 -0800, Rob Sargent wrote:
>>>
>>>> On Dec 8, 2018, at 3:12 PM, Andres Freund <andres(at)anarazel(dot)de> wrote:
>>>>
>>>> On 2018-12-08 12:06:23 -0800, Jeremy Schneider wrote:
>>>>> On RDS PostgreSQL, the default is 25% of your server memory. This
>>>>> seems
>>>>> to be pretty widely accepted as a good starting point on PostgreSQL.
>>>> FWIW, I think it's widely cited, but also bad advice. 25% for a OLTP
>>>> workload on a 1TB machine with a database size above 25% is a terrible
>>>> idea.
>>>>
>>> Sorry, could you please expand “database size above 25%”? 25% of what?
>> Memory available to postgres (i.e. 100% of the server's memory on a
>> server dedicated to postgres, less if it's shared duty).
>>
>
>
> I think the best advice these days is that you need to triangulate to
> find the best setting for shared_buffers. It's very workload
> dependent, and there isn't even a semi-reliable rule of thumb.
Any advice, approaches to triangulating shared_buffers you can share
would be most helpful
>
>
> cheers
>
>
> andrew
>
>
From | Date | Subject | |
---|---|---|---|
Next Message | Mike Lissner | 2018-12-09 16:03:38 | Re: Errors with schema migration and logical replication — expected? |
Previous Message | Adrian Klaver | 2018-12-09 14:45:27 | Re: Errors with schema migration and logical replication — expected? |
From | Date | Subject | |
---|---|---|---|
Next Message | Rick Otten | 2018-12-09 15:42:40 | Re: Database size 1T but unclear why |
Previous Message | Mariel Cherkassky | 2018-12-09 15:18:55 | Database size 1T but unclear why |