Re: Don't codegen deform code for virtual tuples in expr eval forscan fetch - Mailing list pgsql-hackers

From Soumyadeep Chakraborty
Subject Re: Don't codegen deform code for virtual tuples in expr eval forscan fetch
Date
Msg-id CAE-ML+_k1QafeWvk0=B2k7gY+0isa_qx0+xU-2H1fDSncukbeg@mail.gmail.com
Whole thread Raw
In response to Re: Don't codegen deform code for virtual tuples in expr eval forscan fetch  (Andres Freund <andres@anarazel.de>)
List pgsql-hackers
Hi Andres,

Thank you for your insight and the link offered just the context I needed!

On Wed, Sep 25, 2019 at 1:06 PM Andres Freund <andres@anarazel.de> wrote:
> I'm doubtful this is worth the complexity - and not that we already have
> plenty other places with zero length blocks.

Agreed.

On Wed, Sep 25, 2019 at 1:06 PM Andres Freund <andres@anarazel.de> wrote:
> WRT jit_optimize_above_cost not triggering, I think we need to replace
> the "basic, unoptimized" codegen path with one that does cheap
> optimizations only. The reason we don't do the full optimizations all
> the time is that they're expensive, but there's enough optimizations
> that are pretty cheap.  At some point we'll probably need our own
> optimization pipeline, but I don't want to maintain that right now
> (i.e. if some other people want to help with this aspect, cool)...

I would absolutely love to work on this!

I was thinking the same. Perhaps not only replace the default on the
compile path, but also introduce additional levels. These levels could then
be configured at a granularity lower than the -O0, -O1, .. In other words,
perhaps we could have levels with ad-hoc pass combinations. We could then
maybe have costs associated with each level. I think such a framework
would be ideal.

To summarize this into TODOs:
1. Tune default compilation path optimizations.
2. New costs per optimization level.
3. Capacity to define "levels" with ad-hoc pass combinations that are costing
sensitive.

Is this what you meant by "optimization pipeline"?

--
Soumyadeep

pgsql-hackers by date:

Previous
From: Soumyadeep Chakraborty
Date:
Subject: Re: Don't codegen deform code for virtual tuples in expr eval forscan fetch
Next
From: Ashwin Agrawal
Date:
Subject: Re: heapam_index_build_range_scan's anyvisible