Re: Don't codegen deform code for virtual tuples in expr eval for scan fetch

From: Andres Freund <andres(at)anarazel(dot)de>
To: Soumyadeep Chakraborty <soumyadeep2007(at)gmail(dot)com>
Cc: pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: Re: Don't codegen deform code for virtual tuples in expr eval for scan fetch
Date: 2019-09-27 07:22:56
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers


On 2019-09-25 22:11:51 -0700, Soumyadeep Chakraborty wrote:
> Thank you very much for reviewing my patch!
> On Wed, Sep 25, 2019 at 1:02 PM Andres Freund <andres(at)anarazel(dot)de> wrote:
> > IOW, wherever ExecComputeSlotInfo() is called, we should only actually
> > push the expression step, when ExecComputeSlotInfo does not determine
> > that a) the slot is virtual, b) and fixed (i.e. guaranteed to always be
> > the same type of slot).
> >
> > Does that make sense?
> That is a great suggestion and I totally agree. I have attached a patch
> that achieves this.

I think as done, this has the slight disadvantage of removing the
fast-path for small interpreted expressions, because that explicitly
matches for seeing the EEOP_*_FETCHSOME ops. Look at execExprInterp.c,
* Select fast-path evalfuncs for very simple expressions. "Starting up"
* the full interpreter is a measurable overhead for these, and these
* patterns occur often enough to be worth optimizing.
if (state->steps_len == 3)

So I think we'd have to add a separate fastpath for virtual slots for

What do you think about the attached?


Andres Freund

Attachment Content-Type Size
v1-0001-Reduce-code-duplication-for-ExecJust-Var-operatio.patch text/x-diff 6.9 KB
v1-0002-Don-t-generate-EEOP_-_FETCHSOME-operations-for-sl.patch text/x-diff 11.3 KB

In response to


Browse pgsql-hackers by date

  From Date Subject
Next Message REIX, Tony 2019-09-27 07:29:27 RE: Shared Memory: How to use SYSV rather than MMAP ?
Previous Message Michael Paquier 2019-09-27 07:22:15 Re: pg_upgrade fails with non-standard ACL