On Wed, Nov 2, 2016 at 5:46 PM, Jim Nasby wrote:
> On 10/28/16 2:33 PM, Joshua D. Drake wrote:
>>
>> * A very high shared_buffers (in newer releases, it is not uncommon to
>> have many, many GB of)
>
>
> Keep in mind that you might get very poor results if shared_buffers is
> large, but not large
On 10/28/16 2:33 PM, Joshua D. Drake wrote:
* A very high shared_buffers (in newer releases, it is not uncommon to
have many, many GB of)
Keep in mind that you might get very poor results if shared_buffers is
large, but not large enough to fit the entire database. In that case
buffer replacem
On 10/28/2016 08:44 AM, Warner, Gary, Jr wrote:
I've recently been blessed to move one of my databases onto a huge IBM P8
computer. Its a power PC architecture with 20 8-way cores (so postgres SHOULD
believe there are 160 cores available) and 1 TB of RAM.
I've always done my postgres tuning
On Fri, Oct 28, 2016 at 10:44 AM, Warner, Gary, Jr wrote:
> I've recently been blessed to move one of my databases onto a
> huge IBM P8 computer. Its a power PC architecture with 20 8-way
> cores (so postgres SHOULD believe there are 160 cores available)
> and 1 TB of RAM.
> So . . . what woul
I've recently been blessed to move one of my databases onto a huge IBM P8
computer. Its a power PC architecture with 20 8-way cores (so postgres SHOULD
believe there are 160 cores available) and 1 TB of RAM.
I've always done my postgres tuning with a copy of "pgtune" which says in the
output:
