Re: Making JIT more granular

Hi David:

> Does anyone have any thoughts about this JIT costing? Is this an
> improvement? Is there a better way?
>
>
I think this is an improvement. However I'm not sure how much improvement
& effort we want pay for it. I just shared my thoughts to start this
discussion.

1. Ideally there is no GUC needed at all. For given a operation, like
Expression execution, tuple deform, if we can know the extra cost
of JIT in compile and the saved cost of JIT in execution, we
can choose JIT automatically. But as for now, it is hard to
say both. and we don't have a GUC to for DBA like jit_compile_cost
/ jit_compile_tuple_deform_cost as well. Looks we have some
long way to go for this and cost is always a headache.

2. You calculate the cost to compare with jit_above_cost as:

plan->total_cost * plan->est_loops.

An alternative way might be to consider the rescan cost like
cost_rescan. This should be closer for a final execution cost.
However since it is hard to set a reasonable jit_above_cost,
so I am feeling the current way is OK as well.

3. At implementation level, I think it would be terrible to add
another parameter like est_loops to every create_xxx_plan
in future, An alternative way may be:

typedef struct
{
int est_calls;
} ExtPlanInfo;

void
copyExtPlanInfo(Plan *targetPlan, ExtPlanInfo ext)
{
targetPlan->est_calls = ext.est_calls;
}

create_xxx_plan(..., ExtPlanInfo extinfo)
{
copyExtPlanInfo(plan, extinfo);
}

By this way, it would be easier to add another parameter
like est_calls easily. Not sure if this is over-engineered.

I have gone through the patches for a while, General it looks
good to me. If we have finalized the design, I can do a final
double check.

At last, I think the patched way should be better than
the current way.

--
Best Regards
Andy Fan