Re: Data is copied twice when specifying both child and parent table in publication
От | Jacob Champion |
---|---|
Тема | Re: Data is copied twice when specifying both child and parent table in publication |
Дата | |
Msg-id | 185c4ac8-fbc8-11a5-d721-55f639969eb8@timescale.com обсуждение исходный текст |
Ответ на | Re: Data is copied twice when specifying both child and parent table in publication (Amit Kapila <amit.kapila16@gmail.com>) |
Ответы |
RE: Data is copied twice when specifying both child and parent table in publication
|
Список | pgsql-hackers |
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
В списке pgsql-hackers по дате отправления: