Re: [PERFORM] [GENERAL] [pgadmin-support] Issue with a hanging apply process on the replica db after vacuum works on primary

2015-03-20 Thread Vladimir Borodin
19 марта 2015 г., в 20:30, Sergey Shchukin shchukin@gmail.com написал(а): 17.03.2015 13:22, Sergey Shchukin пишет: 05.03.2015 11:25, Jim Nasby пишет: On 2/27/15 5:11 AM, Sergey Shchukin wrote: show max_standby_streaming_delay; max_standby_streaming_delay

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

2016-05-25 Thread Vladimir Borodin
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] DIsk I/O from pg_stat_activity

2016-03-13 Thread Vladimir Borodin
> 13 марта 2016 г., в 20:39, Artem Tomyuk написал(а): > > Hi all. > > Is there any way of how to retrieve information from pg_stat_activity (its > not very comfort to get it from iotop, because its not showing full text of > query) which query generates or consumes the

Re: [PERFORM] Planner do seq scan on empty master partitioned table

2016-08-11 Thread Vladimir Borodin
> 11 авг. 2016 г., в 13:46, Andrey Zhidenkov > написал(а): > > I have a table (registry.entry) which has ~ 100 inherited tables. This > is a master table and it's empty: > > postgres@db=# select count(*) from only registry.entry; > count > --- > 0 > (1 row)

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

2016-07-04 Thread Vladimir Borodin
> 13 июня 2016 г., в 21:58, Vladimir Borodin <r...@simply.name> написал(а): > >> >> 13 июня 2016 г., в 0:51, Andres Freund <and...@anarazel.de >> <mailto:and...@anarazel.de>> написал(а): >> >> Hi Vladimir, >> >> Thanks for th

Re: [PERFORM] Backup taking long time !!!

2017-01-22 Thread Vladimir Borodin
> 20 янв. 2017 г., в 19:59, Stephen Frost написал(а): > >>> How are you testing your backups..? Do you have page-level checksums >>> enabled on your database? >> >> Yep, we use checksums. We restore latest backup with recovery_target = >> 'immediate' and do COPY

Re: [PERFORM] Backup taking long time !!!

2017-01-20 Thread Vladimir Borodin
> 20 янв. 2017 г., в 15:22, Stephen Frost написал(а): >> >> This process can be automatized by some applications like barman >> http://www.pgbarman.org/ > > Last I checked, barman is still single-threaded. > > If the database is large enough that you need multi-process

Re: [PERFORM] Backup taking long time !!!

2017-01-20 Thread Vladimir Borodin
> 20 янв. 2017 г., в 16:40, Stephen Frost написал(а): > > Vladimir, > >> Increments in pgbackrest are done on file level which is not really >> efficient. We have done parallelism, compression and page-level increments >> (9.3+) in barman fork [1], but unfortunately guys

Re: [PERFORM] Backup taking long time !!!

2017-01-20 Thread Vladimir Borodin
> 20 янв. 2017 г., в 18:06, Stephen Frost написал(а): > > Right, without incremental or compressed backups, you'd have to have > room for 7 full copies of your database. Have you looked at what your > incrementals would be like with file-level incrementals and compression?

Re: [PERFORM] Questionaire: Common WAL write rates on busy servers.

2017-04-25 Thread Vladimir Borodin
Hi Andres. > 25 апр. 2017 г., в 7:17, Andres Freund написал(а): > > Hi, > > I've lately seen more and more installations where the generation of > write-ahead-log (WAL) is one of the primary bottlenecks. I'm curious > whether that's primarily a "sampling error" of mine, or