Heikki Linnakangas <hlinnaka@iki.fi> writes:
> On 29/12/2023 01:42, Tom Lane wrote:
>> I didn't stop to trace the details but I'm pretty sure this is why
>> you're getting the bogus extra projections shown in the 0005 patch.
> They're not bogus. With the patches, projecting away the junk columns is
> visible in the plan as an extra Result node, while currently it's done
> as an implicit step in the executor. That seems fine and arguably an
> even more honest representation of what's happening, although I don't
> like the extra verbosity in EXPLAIN output.
I didn't bring it up in my previous message, but I'm not really on
board with trying to get rid of the executor junkfilter. It seems
to me that that code is probably faster than a general-purpose
projection, and surely faster than an extra Result node, so I think
that is not a goal that would improve matters.
However, what I *was* trying to say is that I think those projections
occur because the lower-level plan node is still outputting the
columns you want to suppress, and then the planner realizes that it
needs a projection to create the shortened tlist. But that's not
saving any work, because we still computed the expensive function :-(.
We need a more thorough treatment of the problem to ensure that the
lower-level plan nodes don't emit these columns either.
> Related to this, we are not currently costing the target list evaluation
> correctly for index-only scans.
Right, and we're dumb in other ways too: if the index can return
f(x) but not x, we fail to realize that we can use it for an IOS
in the first place, because there's an assumption that we'd better
be able to fetch x. Currently I think the best way around that
might be via the other discussion that's going on about unifying
regular indexscans and index-only scans [1]. If we do that then
we could postpone the decision about whether we actually need x
itself, and perhaps that would simplify getting this right.
I'm kind of inclined to think that it'd be best to push the
other discussion forward first, and come back to this area
when it's done, because that will be touching a lot of the
same code as well as (maybe) simplifying the planner's problem.
regards, tom lane
[1] https://www.postgresql.org/message-id/20230609000600.syqy447e6metnvyj%40awork3.anarazel.de