Re: Index AM API cleanup - Mailing list pgsql-hackers

From Kirill Reshke
Subject Re: Index AM API cleanup
Date
Msg-id CALdSSPjbCO5HYOK5NhG53ijmVc9Tq4P74_wpaHSejXcNPgLg8A@mail.gmail.com
Whole thread Raw
Responses Re: Index AM API cleanup
List pgsql-hackers
On Thu, 22 Aug 2024 at 00:25, Mark Dilger <mark.dilger@enterprisedb.com> wrote:
>
> Hackers,
>
> The index access method API mostly encapsulates the functionality of in-core index types, with some lingering
oversightsand layering violations.  There has been an ongoing discussion for several release cycles concerning how the
APImight be improved to allow interesting additional functionality.  That discussion has frequently included patch
proposalsto support peculiar needs of esoteric bespoke access methods, which have little interest for the rest of the
community.
>
> For your consideration, here is a patch series that takes a different approach.  It addresses many of the limitations
andlayering violations, along with introducing test infrastructure to validate the changes.  Nothing in this series is
intendedto introduce new functionality to the API.  Any such, "wouldn't it be great if..." type suggestions for the API
areout of scope for this work.  On the other hand, this patch set does not purport to fix all such problems; it merely
movesthe project in that direction. 
>
> For validation purposes, the first patch creates shallow copies of hash and btree named "xash" and "xtree" and
introducessome infrastructure to run the src/test/regress and src/test/isolation tests against them without needing to
duplicatethose tests.  Numerous failures like "unexpected non-btree AM" can be observed in the test results. 
>
> Also for validation purposes, the second patch creates a deep copy of btree named "treeb" which uses modified copies
ofthe btree implementation rather than using the btree implementation by reference.  This allows for more
experimentation,but might be more code than the community wants.  Since this is broken into its own patch, it can be
excludedfrom what eventually gets committed.  Even if we knew a priori that this "treeb" test would surely never be
committed,it still serves to help anybody reviewing the patch series to experiment with those other changes without
havingto construct such a test index AM individually. 
>
> The next twenty patches are a mix of fixes of various layering violations, such as not allowing non-core index AMs
fromuse in replica identity full, or for speculative insertion, or for foreign key constraints, or as part of merge
join;with updates to the "treeb" code as needed.  The changes to "treeb" are broken out so that they can also easily be
excludedfrom whatever gets committed. 
>
> The final commit changes the ordering of the strategy numbers in treeb.  The name "treeb" is a rotation of "btree",
andindeed the strategy numbers 1,2,3,4,5 are rotated to 5,1,2,3,4.  The fact that treeb indexes work properly after
thischange is meant to demonstrate that the core changes have been sufficient to address the prior dependency on btree
strategynumber ordering.  Again, this doesn't need to be committed; it might only serve to help reviewers in
determiningif the functional changes are correct. 
>
> Not to harp on this too heavily, but please note that running the core regression and isolation tests against xash,
xtree,and treeb are known not to pass.  That's the point.  But by the end of the patch series, the failures are limited
toEXPLAIN output changes; the query results themselves are intended to be consistent with the expected test output.  To
avoidbreaking `make check-world`, these test modules are not added to the test schedule.  They are also, at least for
now,only useable from make, not from meson. 
>
> Internal development versions 1..16 not included.  Andrew, Peter, and Alex have all provided reviews internally and
arecc'd here.  Patch by me.  Here is v17 for the community: 
>
>
>
> —
> Mark Dilger
> EnterpriseDB: http://www.enterprisedb.com
> The Enterprise PostgreSQL Company


Hi! Why is the patch attached as .tar.bz2? Usually raw patches are sent here...

--
Best regards,
Kirill Reshke



pgsql-hackers by date:

Previous
From: Nathan Bossart
Date:
Subject: Re: allow changing autovacuum_max_workers without restarting
Next
From: Gabriele Bartolini
Date:
Subject: Re: RFC: Additional Directory for Extensions