timescaledb
timescaledb copied to clipboard
Prevent parallel DecompressChunk in queries with LIMIT
In queries with LIMIT a parallel plan is quite often less desirable due to startup cost and changed ordering behaviour.
With LIMIT, the slower paths should normally get disabled through the startup cost, right? Maybe we can tweak the costs there so that it works? Our cost model for DecompressChunk is kind of bad already, more special cases probably make it even more difficult to debug (e.g. if we ever want to fix these mysterious plan changes in transparent_decompression
test that Erik mentioned recently).