public inbox for [email protected]  

help / color / mirror / Atom feed

From: Tomas Vondra <[email protected]>
To: Alvaro Herrera <[email protected]>
Cc: Amit Kapila <[email protected]>
Cc: Pg Hackers <[email protected]>
Subject: Re: bogus: logical replication rows/cols combinations
Date: Sun, 1 May 2022 22:53:46 +0200
Message-ID: <[email protected]> (raw)
In-Reply-To: <[email protected]>
References: <[email protected]>



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

view thread (3+ messages)

reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: [email protected]
  Cc: [email protected], [email protected], [email protected], [email protected]
  Subject: Re: bogus: logical replication rows/cols combinations
  In-Reply-To: <[email protected]>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox