Re: [HACKERS] logical replication worker and statistics - Mailing list pgsql-hackers

From Stas Kelvich
Subject Re: [HACKERS] logical replication worker and statistics
Date
Msg-id D77A1BDB-95AA-49F4-9BC9-36D8DA43D08B@postgrespro.ru
Whole thread Raw
In response to Re: [HACKERS] logical replication worker and statistics  (Noah Misch <noah@leadboat.com>)
Responses Re: [HACKERS] logical replication worker and statistics  (Peter Eisentraut <peter.eisentraut@2ndquadrant.com>)
List pgsql-hackers
> On 10 Apr 2017, at 05:20, Noah Misch <noah@leadboat.com> wrote:
>
> On Wed, Apr 05, 2017 at 05:02:18PM +0300, Stas Kelvich wrote:
>>> On 27 Mar 2017, at 18:59, Robert Haas <robertmhaas@gmail.com> wrote:
>>> On Mon, Mar 27, 2017 at 11:14 AM, Fujii Masao <masao.fujii@gmail.com> 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 autovacuum from working on
>>>> those tables properly.
>>>
>>> Yeah, that doesn't sound good.
>>
>> Seems that nobody is working on this, so i’m going to create the patch.
>
> [Action required within three days.  This is a generic notification.]
>
> 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 us know.  Otherwise, please observe the policy on
> open item ownership[1] and send a status update within three calendar days of
> this message.  Include a date for your subsequent status update.  Testers may
> discover new open items at any time, and I want to plan to get them all fixed
> well in advance of shipping v10.  Consequently, I will appreciate your efforts
> toward speedy resolution.  Thanks.
>
> [1] https://www.postgresql.org/message-id/20170404140717.GA2675809%40tornado.leadboat.com

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.

Also i’ve added statistics checks to logrep tap tests, but that is probably quite fragile
without something like wait_for_stats() from regression test stats.sql.





Stas Kelvich
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company



-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Attachment

pgsql-hackers by date:

Previous
From: Álvaro Hernández Tortosa
Date:
Subject: [HACKERS] Some thoughts about SCRAM implementation
Next
From: David Rowley
Date:
Subject: [HACKERS] pg_stats_ext view does not seem all that useful