[PERFORM] 9.4 -> 9.5 regression with queries through pgbouncer on RHEL 6

Hi all.We have found that queries through PgBouncer 1.7.2 (with transaction pooling) to local PostgreSQL are almost two times slower in 9.5.3 than in 9.4.8 on RHEL 6 hosts (all packages are updated to last versions). Meanwhile the problem can’t be reproduced i.e. on Ubuntu 14.04 (also

Re: [PERFORM] Testing in AWS, EBS

There are many factors that can affect EBS performance. For example, the type of EBS volume, the instance type, whether EBS-optimized is turned on or not, etc. Without the details, then there is no apples to apples comparsion... Rayson == Open

Re: [PERFORM] index fragmentation on insert-only table with non-unique column

On Tue, May 24, 2016 at 10:39 AM, Justin Pryzby wrote: > Summary: Non-unique btree indices are returning CTIDs for rows with same > value of indexed column not in logical order, imposing a high performance > penalty. > > Running PG 9.5.3 now, we have a time-based partitions

Re: [PERFORM] Testing in AWS, EBS

Indeed, old-style disk EBS vs new-style SSd EBS. Be aware that EBS traffic is considered as part of the total "network" traffic, and each type of instance has different limits on maximum network throughput. Those difference are very significant, do tests on the same volume between two different

Re: [PERFORM] Testing in AWS, EBS

Actually, when "EBS-Optimized" is on, then the instance gets dedicated bandwidth to EBS. Rayson == Open Grid Scheduler - The Official Open Source Grid Engine http://gridscheduler.sourceforge.net/

Re: [PERFORM] index fragmentation on insert-only table with non-unique column

On Tue, May 24, 2016 at 11:23:48PM -0700, Jeff Janes wrote: > > But note the non-uniqueness of the index column: > > ts=# SELECT recordopeningtime, COUNT(1) FROM cdrs_huawei_pgwrecord WHERE > > recordopeningtime>='2016-05-21' AND recordopeningtime<'2016-05-22' GROUP BY > > 1 ORDER BY 2 DESC; > >

Re: [PERFORM] index fragmentation on insert-only table with non-unique column

On Tue, May 24, 2016 at 09:16:20PM -0700, Peter Geoghegan wrote: > On Tue, May 24, 2016 at 10:39 AM, Justin Pryzby wrote: > > Postgres seems to assume that the high degree of correlation of the table > > column seen in pg_stats is how it will get data from the index scan,