Account for CPU tuple cost in DecompressChunk

[akuzm]

It was always zero due to a typo.

Fixes #5481

Disable-check: force-changelog-file

[codecov]

Codecov Report

Attention: Patch coverage is 85.71429% with 1 line in your changes missing coverage. Please review.

Project coverage is 82.32%. Comparing base (59f50f2) to head (e139896).
Report is 688 commits behind head on main.

Files with missing lines	Patch %	Lines
tsl/src/nodes/decompress_chunk/decompress_chunk.c	80.00%	0 Missing and 1 partial ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #7551      +/-   ##
==========================================
+ Coverage   80.06%   82.32%   +2.25%     
==========================================
  Files         190      238      +48     
  Lines       37181    43724    +6543     
  Branches     9450    10972    +1522     
==========================================
+ Hits        29770    35994    +6224     
- Misses       2997     3397     +400     
+ Partials     4414     4333      -81     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[mkindahl]

You are removing the costs from most of the plans (which I think is a good thing since it reduces the risk of flakes and the costs are not part of these tests), but I do not see any test that demonstrates that your fix actually works, i.e., that the cost is non-zero for some query.

[akuzm]

You are removing the costs from most of the plans (which I think is a good thing since it reduces the risk of flakes and the costs are not part of these tests), but I do not see any test that demonstrates that your fix actually works, i.e., that the cost is non-zero for some query.

All the plan changes demonstrate that it actually has an effect, no? This is how we normally check the cost changes.

[mkindahl]

You are removing the costs from most of the plans (which I think is a good thing since it reduces the risk of flakes and the costs are not part of these tests), but I do not see any test that demonstrates that your fix actually works, i.e., that the cost is non-zero for some query.

All the plan changes demonstrate that it actually has an effect, no? This is how we normally check the cost changes.

Well, the fact that there are plan changes demonstrate that there is a cost changes, but not in what direction. For example, if the CPU cost is zero for DecompressChunk why is it then replacing the index scan under the DecompressChunk with a sequence scan?

Also, if I look at this line from the patch (it is a removed row), it does not show up as zero, so it is not clear what this does.

->  Custom Scan (DecompressChunk) on _timescaledb_internal._hyper_1_1_chunk  (cost=1.06..63.44 rows=3000 width=12)

[akuzm]

Also, if I look at this line from the patch (it is a removed row), it does not show up as zero, so it is not clear what this does.

It shows the cost of the underlying plan.

I can add a trivial test that shows costs, but not sure what use it has, and it's going to make the tests more fragile because the costs sometimes fluctuate because of floating point errors and so on.

[antekresic]

This fixes #5481 ?

[akuzm]

This fixes #5481 ?

Yeah, looks like it, didn't realize we tried to fix it already.

[antekresic]

I agree with Mats here. I would like if there was a test case demonstrating that tuple costs are included in the cost calculation by at least a couple test cases. I understand this is flaky, I would still add the test cases and figure out how to resolve the flakiness later on. There should be tuple counts which provide stable enough fp calculation results for this not to be an issue.

Besides that, we need to be aware that tuple costs as such cannot be thought of as in vanilla PG way. cpu_tuple_cost will probably be influenced by the number of columns you need to decompress hence it cannot be static like here. We should probably document this.