From: Eric Ridge <eebbrr@gmail.com>
Content-Type: text/plain;
	charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3776.700.51\))
Subject: IndexAccessMethod API & Index Only Scans
Message-Id: <63F9F123-F5ED-4B2C-BA09-12E22B36870D@gmail.com>
Date: Fri, 27 Sep 2024 09:33:13 -0400
To: pgsql-hackers@postgresql.org
Archived-At: <https://www.postgresql.org/message-id/63F9F123-F5ED-4B2C-BA09-12E22B36870D%40gmail.com>
Precedence: bulk

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. =20

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=3D=3D1, 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=