Re: bogus: logical replication rows/cols combinations
От | Alvaro Herrera |
---|---|
Тема | Re: bogus: logical replication rows/cols combinations |
Дата | |
Msg-id | 202204271057.6mdn7n5ccvge@alvherre.pgsql обсуждение исходный текст |
Ответ на | Re: bogus: logical replication rows/cols combinations (Amit Kapila <amit.kapila16@gmail.com>) |
Ответы |
Re: bogus: logical replication rows/cols combinations
|
Список | pgsql-hackers |
On 2022-Apr-27, Amit Kapila wrote: > On Wed, Apr 27, 2022 at 3:13 PM Alvaro Herrera <alvherre@alvh.no-ip.org> wrote: > > > Changing this to behave the way you expect would be quite difficult, > > > because at the moment we build a single OR expression from all the row > > > filters. We'd have to keep the individual expressions, so that we can > > > build a column list for each of them (in order to ignore those that > > > don't match). > > > > I think we should do that, yeah. > > This can hit the performance as we need to evaluate each expression > for each row. So we do things because they are easy and fast, rather than because they work correctly? > > ... In fact I think they are quite orthogonal: probably you should be > > able to publish a partitioned table in two publications, with different > > rowfilters and different column lists (which can come from the > > topmost partitioned table), and each partition should still work in the > > way I describe above. > > We consider the column lists or row filters for either the partition > (on which the current operation is performed) or partitioned table > based on 'publish_via_partition_root' parameter of publication. OK, but this isn't relevant to what I wrote. -- Álvaro Herrera PostgreSQL Developer — https://www.EnterpriseDB.com/
В списке pgsql-hackers по дате отправления: