|From:||Andres Freund <andres(at)anarazel(dot)de>|
|To:||Soumyadeep Chakraborty <soumyadeep2007(at)gmail(dot)com>|
|Subject:||Re: Don't codegen deform code for virtual tuples in expr eval for scan fetch|
|Views:||Raw Message | Whole Thread | Download mbox | Resend email|
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?
|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|