Message-ID: <185c4ac8-fbc8-11a5-d721-55f639969eb8@timescale.com>
Date: Mon, 27 Mar 2023 16:01:59 -0700
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101
 Thunderbird/102.7.1
From: Jacob Champion <jchampion@timescale.com>
Subject: Re: Data is copied twice when specifying both child and parent table
 in publication
To: Amit Kapila <amit.kapila16@gmail.com>,
 "wangw.fnst@fujitsu.com" <wangw.fnst@fujitsu.com>
Cc: Andres Freund <andres@anarazel.de>, vignesh C <vignesh21@gmail.com>,
 Peter Smith <smithpb2250@gmail.com>,
 "Takamichi Osumi (Fujitsu)" <osumi.takamichi@fujitsu.com>,
 "shiy.fnst@fujitsu.com" <shiy.fnst@fujitsu.com>,
 "houzj.fnst@fujitsu.com" <houzj.fnst@fujitsu.com>,
 Amit Langote <amitlangote09@gmail.com>,
 Peter Eisentraut <peter.eisentraut@enterprisedb.com>,
 "pgsql-hackers@lists.postgresql.org" <pgsql-hackers@lists.postgresql.org>,
 Dilip Kumar <dilipbalaut@gmail.com>, Greg Nancarrow <gregn4422@gmail.com>
References: <OS3PR01MB62751414E4DABF144F5E481C9E529@OS3PR01MB6275.jpnprd01.prod.outlook.com>
 <CAHut+Pt+1PNx6VsZ-xKzAU-18HmNXhjCC1TGakKX46Wg7YNT1Q@mail.gmail.com>
 <OS3PR01MB6275FB5397C6A647F262A3A69E009@OS3PR01MB6275.jpnprd01.prod.outlook.com>
 <CALDaNm3ZzNJ6Y1iX=PBYCcCU+EPm4=9LVXFin5gvQ9XkEzc8UQ@mail.gmail.com>
 <OS3PR01MB6275C62FF1D1CDE4FCBF61339E079@OS3PR01MB6275.jpnprd01.prod.outlook.com>
 <20230207202834.c2ptvco7dv57t3hi@awork3.anarazel.de>
 <OS3PR01MB62758DFA4FE5BFA7CA0815329ED89@OS3PR01MB6275.jpnprd01.prod.outlook.com>
 <CAA4eK1LCzvPLVHHXn+VcGmFHApKtbpaNF1UFed3qE8=GhPzPGw@mail.gmail.com>
 <OSZPR01MB62783EDCE9DDC21D35B789209EBD9@OSZPR01MB6278.jpnprd01.prod.outlook.com>
 <eb7047d0-6db1-b526-f44a-fad58eda35d4@timescale.com>
 <CAA4eK1+mzLsECnKzRoof8G2DgH-OBTdjYrP5Ed5QgBBpw2Xe8A@mail.gmail.com>
 <CAAWbhmjjJu4eFMC3P-_dJHL=ei5eJ1rvRm2DrYff7kTB6fT+oQ@mail.gmail.com>
 <CAA4eK1LhTALc2Zw3CuvCzO9h_uyLOb6cbeLBmcc6v3Gb--cNoA@mail.gmail.com>
Content-Language: en-US
In-Reply-To: <CAA4eK1LhTALc2Zw3CuvCzO9h_uyLOb6cbeLBmcc6v3Gb--cNoA@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Archived-At: <https://www.postgresql.org/message-id/185c4ac8-fbc8-11a5-d721-55f639969eb8%40timescale.com>
Precedence: bulk

On Mon, Mar 20, 2023 at 11:22 PM Amit Kapila <amit.kapila16@gmail.com>
wrote:
> If the tests you have in mind are only related to this patch set then
> feel free to propose them here if you feel the current ones are not
> sufficient.

I think the new tests added by Wang cover my concerns (thanks!). I share
Peter's comment that we don't seem to have a regression test covering
only the bug description itself -- just ones that combine that case with
row and column restrictions -- but if you're all happy with the existing
approach then I have nothing much to add there.

I was staring at this subquery in fetch_table_list():

> +                        "              ( SELECT array_agg(a.attname ORDER BY a.attnum)\n"
> +                        "                FROM pg_attribute a\n"
> +                        "                WHERE a.attrelid = gpt.relid AND\n"
> +                        "                      a.attnum = ANY(gpt.attrs)\n"
> +                        "              ) AS attnames\n"

On my machine this takes up roughly 90% of the runtime of the query,
which makes for a noticeable delay with a bigger test case (a couple of
FOR ALL TABLES subscriptions on the regression database). And it seems
like we immediately throw all that work away: if I understand correctly,
we only use the third column for its interaction with DISTINCT. Would it
be enough to just replace that whole thing with gpt.attrs?

Thanks,
--Jacob