On Wed, Jul 2, 2025 at 8:59 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
>
> Arseniy Mukhin <arseniy.mukhin.dev@gmail.com> writes:
> > Sorry, I think I wasn't clear enough. I agree with this logic, but I
> > think it implies an impossible scenario for the "equals" case. The
> > scenario where during a scan we first have keys that are less than
> > orig_datum, and then a key that is equal to orig_datum. Why I think
> > such a scenario is impossible: GIN uses partial_key as a lower bound
> > when positioning the start of a partial match scan. So if there is any
> > key in the index that is equal to "partial key", it must be the very
> > first key in the scan. Then if the very first key in the scan is less
> > than orig_datum, that means partial_key was also less than orig_datum
> > (because partial_key is a lower bound). And the only reason
> > partial_key might not be equal to orig_datum is that there is no value
> > equal to orig_datum in the index type. So we can say that if the very
> > first key in the scan is less than orig_datum, then there is no key in
> > the index that could be equal to orig_datum, and we can stop right
> > there.
>
> OK, I got your point finally. It seems perhaps a little fragile
> to write the code like this, but I agree that it should work.
>
> v5 attached incorporates your test additions and responds to your
> other review suggestions. Also, I changed the representation of
> the opclass strategy numbers to use 4 bits for the btree strategy,
> because I realized that we could write the strategy numbers in the
> .sql file as hex literals and thereby improve readability --- the
> RHS type and the btree strategy are now independent hex digits
> in the DDL.
Thanks!
Sql file is definitely more readable now. I think the patch is ready.
Should I move it to "Ready for Committer" status or do we need more
reviews or something?
Best regards,
Arseniy Mukhin
