Hi all!  Congrats on releasing v17!

I'm adding support for Index Only Scans to a custom IAM impl and I've got a 
little dilemma.  

My IAM implementation is essentially a composite index that might have up to 32 
columns and while it can return any column in the index definition it's quite 
expensive to do so.  It doesn't have an already formed index tuple sitting 
right there like the built-in btree index does.  Returning 1 or 2 columns is 
usually a win over the regular Index Scan version, but more than that and it's 
at least a wash if not a total loss.

Since not all Index Only Scans need *all* the columns, was there ever any 
thought around providing the required attnos as a field on IndexScanDescData?  
That information seems to be there in the nodeindexonlyscan.c machinery.

As a compromise, I've settled on my `amcanreturn` function saying it only knows 
how to return attno==1, which is sufficient for some query patterns, but I'd 
like to be able to have my index directly feed tuples into aggregate plans and 
such too.  It's just too expensive for me to always return all the columns when 
generally maybe only 1 or 2 are needed (there doesn't seem to be a way to weave 
that into the cost estimations, but that wouldn't matter if I knew which 
specific columns I need to fetch out of my index).

I'm pretty familiar with the IAM and the internals around it, but maybe I've 
missed something -- can I get at this information some other way?

Thanks for your time and consideration!

eric

Reply via email to