> On Saturday, January 29, 2022 8:31 AM Andres Freund <and...@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
