On Wed, Jun 26, 2019 at 10:49 PM Henri Cook <github@henricook.com> wrote:
> My thanks for such a speedy reply and your analysis. This sounds like it would be really useful for preventing
'unnecessary'retries. Is there a page/mailing list/group for feature requests where I or we could formalise and track
it?
The first step is coincidentally already proposed for v13, for an
unrelated reason: https://commitfest.postgresql.org/23/2169/ . That'd
let us predicate-lock heap tuples given only the TID from an index,
where we currently have to lock the whole heap page. Then it should
be fairly easy to make the change to nodeIndexonlyscan.c (after we
convince ourselves that it's correct).
After thinking more about this case, though, I'm not sure it'd help
much. We also take a page-level lock in the index itself
(nbtsearch.c), and that's probably unavoidable. In this case 44 and
33 are on the same index page.
Hmm. Well... it might not be totally unavoidable. Perhaps we could
take a predicate lock on the heap tuple and also on the index tuple
(rather than index page), in the specific case that it is an = search
on a unique index that found an all-visible match. Otherwise take a
page lock on the index as now. Not sure if that's logically sound,
and there are probably some tricky details...
--
Thomas Munro
https://enterprisedb.com