Re: logical replication worker and statistics

From: Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com>
To: Stas Kelvich <s(dot)kelvich(at)postgrespro(dot)ru>
Cc: Noah Misch <noah(at)leadboat(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, Fujii Masao <masao(dot)fujii(at)gmail(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: logical replication worker and statistics
Date: 2017-04-12 03:41:46
Message-ID: 4b337a8f-121c-6666-c895-55b0aa9d0964@2ndquadrant.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 4/10/17 13:06, Stas Kelvich wrote:
>
>> On 10 Apr 2017, at 19:50, Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com> 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 amounts of changed tuples,
>>> but seems that it is already smoothly handled on relation level. So call to
>>> pgstat_report_stat() is enough.
>>
>> I wonder whether we need a similar call somewhere in tablesync.c. It
>> seems to work without it, though.
>
> I thought it spins up the same worker from worker.c.

It depends on which of the various tablesync scenarios happens. If the
apply lags behind the tablesync, then the apply doesn't process commit
messages until it has caught up. So the part of the code you patched
wouldn't be called.

--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Noah Misch 2017-04-12 03:41:48 Re: SUBSCRIPTIONS and pg_upgrade
Previous Message Tom Lane 2017-04-12 03:34:10 Re: error handling in RegisterBackgroundWorker