RE: row filtering for logical replication

> On Saturday, January 29, 2022 8:31 AM Andres Freund <andres@anarazel.de>
> wrote:
> >
> > Hi,
> >
> > Are there any recent performance evaluations of the overhead of row
> > filters? I think it'd be good to get some numbers comparing:
> 
> Thanks for looking at the patch! Will test it.
> 
> > >          case REORDER_BUFFER_CHANGE_INSERT:
> > >              {
> > > -                HeapTuple    tuple = &change->data.tp.newtuple->tuple;
> > > +                /*
> > > +                 * Schema should be sent before the logic that replaces the
> > > +                 * relation because it also sends the ancestor's relation.
> > > +                 */
> > > +                maybe_send_schema(ctx, change, relation, relentry);
> > > +
> > > +                new_slot = relentry->new_slot;
> > > +
> > > +                ExecClearTuple(new_slot);
> > > +                ExecStoreHeapTuple(&change->data.tp.newtuple->tuple,
> > > +                                   new_slot, false);
> >
> > Why? This isn't free, and you're doing it unconditionally. I'd bet this alone is
> > noticeable slowdown over the current state.
>
> It was intended to avoid deform the tuple twice, once in row filter execution
> ,second time in logicalrep_write_tuple. But I will test the performance
> impact of this and improve this if needed.

I removed the unnecessary ExecClearTuple here, I think the ExecStoreHeapTuple
here doesn't allocate or free any memory and seems doesn't have a noticeable
impact from the perf result[1]. And we need this to avoid deforming the tuple
twice. So, it looks acceptable to me.

[1] 0.01%     0.00%  postgres  pgoutput.so         [.] ExecStoreHeapTuple@plt

Best regards,
Hou zj