Re: [PATCH] Use indexes on the subscriber when REPLICA IDENTITY is full on the publisher

From: Önder Kalacı <onderkalaci(at)gmail(dot)com>
To: Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>
Cc: PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: [PATCH] Use indexes on the subscriber when REPLICA IDENTITY is full on the publisher
Date: 2022-09-14 12:04:00
Message-ID: CACawEhWcLevu72AtdM1G6vK_8EhmRXb77NY5eFf1vht2i9Xh8w@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi,

> >
> > Oh, I haven't considered inherited tables. That seems right, the
> statistics of the children are not updated when the parent is analyzed.
> >
> >>
> >> Now, the point I was worried about was what if the changes in child
> >> tables (*_part1, *_part2) are much more than in tbl1? In such cases,
> >> we may not invalidate child rel entries, so how will logical
> >> replication behave for updates/deletes on child tables? There may not
> >> be any problem here but it is better to do some analysis of such cases
> >> to see how it behaves.
> >
> >
> > I also haven't observed any specific issues. In the end, when the user
> (or autovacuum) does ANALYZE on the child, it is when the statistics are
> updated for the child.
> >
>
> Right, I also think that should be the behavior but I have not
> verified it. However, I think it should be easy to verify if
> autovacuum updates the stats for child tables when we operate on only
> one of such tables and whether that will invalidate the cache for our
> case.
>
>
I already added a regression test for this with the title: # Testcase
start: SUBSCRIPTION CAN UPDATE THE INDEX IT USES AFTER ANALYZE - INHERITED
TABLE

I realized that the comments on the test case were confusing, and clarified
those. Attached the new version also rebased onto the master branch.

Thanks,
Onder

Attachment Content-Type Size
v10_0001_use_index_on_subs_when_pub_rep_ident_full.patch application/octet-stream 72.4 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message kuroda.hayato@fujitsu.com 2022-09-14 12:26:52 RE: logical replication restrictions
Previous Message kuroda.hayato@fujitsu.com 2022-09-14 11:10:45 RE: logical replication restrictions