Re: bogus: logical replication rows/cols combinations

From: Tomas Vondra <tomas(dot)vondra(at)enterprisedb(dot)com>
To: Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>
Cc: Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>, Pg Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: bogus: logical replication rows/cols combinations
Date: 2022-05-01 20:53:46
Message-ID: 8ccaee59-0333-b4d9-c294-e2f6633853ae@enterprisedb.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 4/30/22 11:28, Alvaro Herrera wrote:
> On 2022-Apr-28, Tomas Vondra wrote:
>
>> Attached is a patch doing the same thing in tablesync. The overall idea
>> is to generate copy statement with CASE expressions, applying filters to
>> individual columns. For Alvaro's example, this generates something like
>>
>> SELECT
>> (CASE WHEN (a < 0) OR (a > 0) THEN a ELSE NULL END) AS a,
>> (CASE WHEN (a > 0) THEN b ELSE NULL END) AS b,
>> (CASE WHEN (a < 0) THEN c ELSE NULL END) AS c
>> FROM uno WHERE (a < 0) OR (a > 0)
>
> I've been reading the tablesync.c code you propose and the idea seems
> correct. (I was distracted by wondering if a different data structure
> would be more appropriate, because what's there looks slightly
> uncomfortable to work with. But after playing around I can't find
> anything that feels better in an obvious way.)
>
> (I confess I'm a bit bothered by the fact that there are now three
> different data structures in our code called PublicationInfo).
>

True. I haven't really thought about naming of the data structures, so
maybe we should name them differently.

> I propose some comment changes in the attached patch, and my
> interpretation (untested) of the idea of optimizing for a single
> publication. (In there I also rename logicalrep_relmap_free_entry
> because it's confusing. That should be a separate patch but I didn't
> split it before posting, apologies.)
>
>> There's a couple options how we might optimize this for common cases.
>> For example if there's just a single publication, there's no need to
>> generate the CASE expressions - the WHERE filter will do the trick.
>
> Right.
>

OK, now that we agree on the approach in general, I'll look into these
optimizations (and the comments from your patch).

regards

--
Tomas Vondra
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2022-05-01 21:12:26 Re: Libpq single-row mode slowness
Previous Message Daniele Varrazzo 2022-05-01 20:35:52 Libpq single-row mode slowness