Horton
Menu

Re: Index AM API cleanup

Peter Eisentraut <peter@eisentraut.org>

View thread
From: Peter Eisentraut <peter@eisentraut.org>
To: Paul A Jungwirth <pj@illuminatedcomputing.com>, Mark Dilger <mark.dilger@enterprisedb.com>
Cc: PostgreSQL Hackers <pgsql-hackers@postgresql.org>, Andrew Dunstan <andrew@dunslane.net>, Alex Wang <alex.wang@enterprisedb.com>
Date: 2025-02-07T15:53:46Z
Lists: pgsql-hackers

Attachments

On 04.02.25 14:31, Peter Eisentraut wrote:
> On 03.02.25 12:08, Peter Eisentraut wrote:
>> Yeah, actually this turned out to be unnecessary, because you can 
>> easily obtain the AM OID from the passed-in opclass ID.  So I have 
>> fixed it that way.  I have committed this whole patch set now with the 
>> mentioned adjustments.  I'll post a rebased version of the main patch 
>> set soon.
> 
> I picked off two more patches from the full patch series that can be 
> dealt with easily.  These are
> 
> - Support non-btree indexes for foreign keys
> - Allow non-btree speculative insertion indexes
> 
> (v19-0012 and v19-0013)
> 
> The version of these patches that were posted in the v19 bundle replaced 
> the hardcoded comparison with BTREE_AM_OID by a check against 
> (indirectly) amcanunique.  But I think that is not necessary, because at 
> that point we already know that we are dealing with a unique index.  The 
> reason for the check against BTREE_AM_OID was that we didn't have a way 
> to get the right strategy number for other index methods.  But now we 
> have, so we can use the strategy translation functions and we don't need 
> to check for btree-ness anymore.
> 
> See attached patches.

I have committed these.

Here is another small issue.  In the v19.2 patches, I had changed the 
argument of the gist strategy translation function from opclass to 
opfamily+opcintype.  This worked well with the existing uses, but when 
rebasing the rest of the main patch set, it seems that the correct value 
of "opcintype" is not always clear or readily available.  And if you 
think about it, we don't need that type, because the strategy mapping 
function is surely the same for all types supported by an opfamily.  So 
we could simplify that by registering the gist stratnum support function 
in a way that you can look it up without having to worry about the type. 
  Apparently, you can't register it with just zero in 
amproclefttype/amprocrighttype, that confuses some DDL commands.  But I 
figure we could put the pseudotype "any" in there, which is moderately 
intuitive.  And then we can drop the opcintype from all the APIs, which 
simplifies things.

See attached patches.  Thoughts?

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

  1. Relax ordering-related hardcoded btree requirements in planning

  2. Support non-btree indexes in get_actual_variable_range()

  3. Convert PathKey to use CompareType

  4. Generalize index support in network support function

  5. Update a code comment

  6. Allow non-btree unique indexes for matviews

  7. Allow non-btree unique indexes for partition keys

  8. Add some opfamily support functions to lsyscache.c

  9. Simplify and generalize PrepareSortSupportFromIndexRel()

  10. Generalize hash and ordering support in amapi

  11. Drop opcintype from index AM strategy translation API

  12. Allow non-btree speculative insertion indexes

  13. Support non-btree indexes for foreign keys

  14. Integrate GistTranslateCompareType() into IndexAmTranslateCompareType()

  15. Convert strategies to and from compare types

  16. Move CompareType to separate header file

  17. Add get_opfamily_name() function

  18. Rename GistTranslateStratnum() to GistTranslateCompareType()

  19. Change gist stratnum function to use CompareType

  20. Rename RowCompareType to CompareType

  21. Improve slightly misleading internal error message

  22. Track scan reversals in MergeJoin

  23. Track sort direction in SortGroupClause

  24. Add stratnum GiST support function

  25. Add amgettreeheight index AM API routine