Re: [PERFORM] Increasing work_mem and shared_buffers on Postgres 9.2 significantly slows down queries

Two possibilities: caching. make sure to run each query several times in a row. zone reclaim mode. If this has gotten turned on turn it back off. How to tell: sysctl -n vm.zone_reclaim_mode Output should be 0. If it's not, then add this to /etc/sysctl.conf: vm.zone_reclaim_mode=0 and run:

Re: [PERFORM] Re: Increasing work_mem and shared_buffers on Postgres 9.2 significantly slows down queries

Am 01.11.2012 21:40, schrieb Marcos Ortiz: Regards, Petr. Tuning PostgreSQL is not just change the postgresql.conf, it includes more things like: - the filesystem that you are using - the kernel version that you using (particularly in Linux systems) - the tuning to kernel variables - the type o

Re: [PERFORM] pg_buffercache

On Tue, Oct 30, 2012 at 1:34 PM, pg noob wrote: > > Hi all, > > I was wondering if it is safe to install pg_buffercache on production > systems? Well, why wouldn't you expect it to be safe? Core extensions should be mostly assumed safe unless there is a good reasons to believe otherwise. That s

[PERFORM] Increasing work_mem and shared_buffers on Postgres 9.2 significantly slows down queries

Hello, I have a PostgreSQL 9.2 instance running on RHEL 6.3, 8-core machine with 16GB of RAM. The server is dedicated to this database, the disks are local RAID10. Given that the default postgresql.conf is quite conservative regarding memory settings, I thought it might be a good idea to allow Pos

[PERFORM] dbt2 performance regresses from 9.1.6 to 9.2.1

Hi there, I work for VMware with our Postgres performance team. We recently came across a dbt2 performance regression from 9.1.6 to 9.2.1. We have done some profiling and don't see anything obvious. Would like to get some suggestions from the community where to investigate further. The average

[PERFORM] pg_buffercache

Hi all, I was wondering if it is safe to install pg_buffercache on production systems? Thank you.

Re: [PERFORM] Prepared statements slow in 9.2 still (bad query plan)

Thanks, default_statistics_target is currently at 500 (I have tried from 100-5000 without any success) Would upping the stats for one specific column help? If so, I presume I should up the stats on the subj column... You may well be onto something wrt the indexes and their usage - this is a no

Re: [PERFORM] Re: Increasing work_mem and shared_buffers on Postgres 9.2 significantly slows down queries

Regards, Petr. Tuning PostgreSQL is not just change the postgresql.conf, it includes more things like: - the filesystem that you are using - the kernel version that you using (particularly in Linux systems) - the tuning to kernel variables - the type of discs that you are using (SSDs are very fa

[PERFORM] Re: Increasing work_mem and shared_buffers on Postgres 9.2 significantly slows down queries

I just found one particularly interesting fact: when I perform the same test on my mid-2010 iMac (OSX 10.7.5) also with Postgres 9.2.1 and 16GB RAM, I don't experience the slow down. Specifically: set work_mem='1MB'; select ...; // running time is ~1800 ms set work_mem='96MB'; select ...' // runnin

Re: [PERFORM] Replaying 48 WAL files takes 80 minutes

On Oct 29, 2012, at 12:42 PM, Jeff Janes wrote: > On Mon, Oct 29, 2012 at 6:05 AM, Albe Laurenz wrote: >> I am configuring streaming replication with hot standby >> with PostgreSQL 9.1.3 on RHEL 6 (kernel 2.6.32-220.el6.x86_64). >> PostgreSQL was compiled from source. >> >> It works fine, excep

Re: [PERFORM] Replaying 48 WAL files takes 80 minutes

On Oct 29, 2012, at 12:42 PM, Jeff Janes wrote: > On Mon, Oct 29, 2012 at 6:05 AM, Albe Laurenz wrote: >> I am configuring streaming replication with hot standby >> with PostgreSQL 9.1.3 on RHEL 6 (kernel 2.6.32-220.el6.x86_64). >> PostgreSQL was compiled from source. >> >> It works fine, excep