IndexAccessMethod API & Index Only Scans

From: Eric Ridge <eebbrr(at)gmail(dot)com>
To: pgsql-hackers(at)postgresql(dot)org
Subject: IndexAccessMethod API & Index Only Scans
Date: 2024-09-27 13:33:13
Message-ID: 63F9F123-F5ED-4B2C-BA09-12E22B36870D@gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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

Browse pgsql-hackers by date

  From Date Subject
Previous Message Junwang Zhao 2024-09-27 13:15:45 general purpose array_sort