I wrote: > I have mostly-working code for approach #3, but I haven't tried to make > EXPLAIN work yet. While looking at that I realized that there's a > pretty good argument for adding the above-mentioned explicit TargetEntry > list representing the index columns to index-only plan nodes. Namely, > that if we don't do it, EXPLAIN will have to go to the catalogs to find > out what's in that index, and this will fall down for "hypothetical" > indexes injected into the planner by index advisors. We could imagine > adding some more hooks to let the advisor inject bogus catalog data at > EXPLAIN time, but on the whole it seems easier and less fragile to just > have the planner include a data structure it has to build anyway into > the finished plan.
> The need for this additional node list field also sways me in a > direction that I'd previously been on the fence about, namely that > I think index-only scans need to be their own independent plan node type > instead of sharing a node type with regular indexscans. It's just too > weird that a simple boolean indexonly property would mean completely > different contents/interpretation of the tlist and quals. Attached is a draft patch for this. It needs some more review before committing, but it does pass regression tests now. One point worth commenting on is that I chose to rename the OUTER and INNER symbols for special varnos to OUTER_VAR and INNER_VAR, along with adding a new special varno INDEX_VAR. It's bothered me for some time that those macro names were way too generic/susceptible to collision; and since I had to look at all the uses anyway to see if the INDEX case needed to be added, this seemed like a good time to rename them. regards, tom lane
-- Sent via pgsql-hackers mailing list (firstname.lastname@example.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers