Re: [HACKERS] logical replication worker and statistics
От | Stas Kelvich |
---|---|
Тема | Re: [HACKERS] logical replication worker and statistics |
Дата | |
Msg-id | D77A1BDB-95AA-49F4-9BC9-36D8DA43D08B@postgrespro.ru обсуждение исходный текст |
Ответ на | Re: [HACKERS] logical replication worker and statistics (Noah Misch <noah@leadboat.com>) |
Ответы |
Re: [HACKERS] logical replication worker and statistics
|
Список | 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
Вложения
В списке pgsql-hackers по дате отправления: