Re: [HACKERS] logical replication worker and statistics

2017-04-14 Thread Peter Eisentraut
On 4/14/17 12:09, Petr Jelinek wrote: > Indeed, if catchup phase didn't happen (because tablesync was faster > than apply) then the commit handler is never called so all the changes > made by copy would be forgotten. Also the tablesync worker might exit > from process_syncing_tables() call which

Re: [HACKERS] logical replication worker and statistics

2017-04-14 Thread Petr Jelinek
On 12/04/17 05:41, Peter Eisentraut wrote: > On 4/10/17 13:06, Stas Kelvich wrote: >> >>> On 10 Apr 2017, at 19:50, Peter Eisentraut >>> wrote: >>> >>> On 4/10/17 05:49, Stas Kelvich wrote: Here is small patch to call statistics in logical worker.

Re: [HACKERS] logical replication worker and statistics

2017-04-11 Thread Peter Eisentraut
On 4/10/17 13:06, Stas Kelvich wrote: > >> On 10 Apr 2017, at 19:50, Peter Eisentraut >> wrote: >> >> On 4/10/17 05:49, Stas Kelvich wrote: >>> Here is small patch to call statistics in logical worker. Originally i >>> thought that stat >>> collection during

Re: [HACKERS] logical replication worker and statistics

2017-04-10 Thread Stas Kelvich
> On 10 Apr 2017, at 19:50, Peter Eisentraut > wrote: > > On 4/10/17 05:49, Stas Kelvich wrote: >> Here is small patch to call statistics in logical worker. Originally i >> thought that stat >> collection during logical replication should manually account

Re: [HACKERS] logical replication worker and statistics

2017-04-10 Thread Peter Eisentraut
On 4/9/17 22:20, Noah Misch wrote: > The above-described topic is currently a PostgreSQL 10 open item. Peter, > since you committed the patch believed to have created it, you own this open > item. If some other commit is more relevant or if this does not belong as a > v10 open item, please let

Re: [HACKERS] logical replication worker and statistics

2017-04-10 Thread Peter Eisentraut
On 4/10/17 05:49, Stas Kelvich wrote: > Here is small patch to call statistics in logical worker. Originally i > thought that stat > collection during logical replication should manually account amounts of > changed tuples, > but seems that it is already smoothly handled on relation level. So

Re: [HACKERS] logical replication worker and statistics

2017-04-10 Thread Stas Kelvich
> On 10 Apr 2017, at 05:20, Noah Misch wrote: > > On Wed, Apr 05, 2017 at 05:02:18PM +0300, Stas Kelvich wrote: >>> On 27 Mar 2017, at 18:59, Robert Haas wrote: >>> On Mon, Mar 27, 2017 at 11:14 AM, Fujii Masao wrote:

Re: [HACKERS] logical replication worker and statistics

2017-04-09 Thread Noah Misch
On Wed, Apr 05, 2017 at 05:02:18PM +0300, Stas Kelvich wrote: > > On 27 Mar 2017, at 18:59, Robert Haas wrote: > > On Mon, Mar 27, 2017 at 11:14 AM, Fujii Masao wrote: > >> Logical replication worker should call pgstat_report_stat()? > >> Currently

Re: [HACKERS] logical replication worker and statistics

2017-04-05 Thread Stas Kelvich
> On 27 Mar 2017, at 18:59, Robert Haas wrote: > > On Mon, Mar 27, 2017 at 11:14 AM, Fujii Masao wrote: >> Logical replication worker should call pgstat_report_stat()? >> Currently it doesn't seem to do that and no statistics about >> table

Re: [HACKERS] logical replication worker and statistics

2017-03-27 Thread Robert Haas
On Mon, Mar 27, 2017 at 11:14 AM, Fujii Masao wrote: > Logical replication worker should call pgstat_report_stat()? > Currently it doesn't seem to do that and no statistics about > table accesses by logical replication workers are collected. > For example, this can prevent

[HACKERS] logical replication worker and statistics

2017-03-27 Thread Fujii Masao
Hi, Logical replication worker should call pgstat_report_stat()? Currently it doesn't seem to do that and no statistics about table accesses by logical replication workers are collected. For example, this can prevent autovacuum from working on those tables properly. Regards, -- Fujii Masao