Hi, On 2018-03-14 09:06:54 +1030, Andrew Dunstan wrote: > I do suspect that the "physical tlist" optimization sometimes turns > out not to be one. It seems perverse to be able to improve a query's > performance by dropping a column.
Yea, it's definitely not always a boon. Especially w/ the newer v10+ project code. I suspect we should largely get rid of it in v12, which presumably will see a storage layer abstraction... It'll be even more worthwhile to get rid of it if we manage to avoid deforming columns that aren't needed but are lower than the currently required columns. I still think we should build bitmasks of required columns during planning. Greetings, Andres Freund
