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
binInhGxDA2ea.bin
Description: index-only-scan-revisions.patch.gz
-- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
