Account for CPU tuple cost in DecompressChunk

[akuzm]

It was always zero due to a typo.

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.