On Wed, Jul 10, 2019 at 1:25 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
> I wonder if we'd be better off to switch over to using data directly
> from the index entry, rather than trying to recover it from the heap.
> We'd then need to make sure that the logic exploits btree's "killed
> index entry" ability, so that dead extremal values are ignored as
> much as possible. But that'd get us out of the broken-HOT-chain
> problem.
I continue to have concerns about the effectiveness of the
kill_prior_tuple mechanism on 9.5+:
https://www.postgresql.org/message-id/flat/CAH2-Wz=SfAKVMv1x9Jh19EJ8am8TZn9f-yECipS9HrrRqSswnA@mail.gmail.com#b20ead9675225f12b6a80e53e19eed9d
Maybe that problem has nothing to do with what you said, but I was
reminded of the fact that it's far from clear how effective
kill_prior_tuple actually is in the real world (i.e. with
concurrency). I guess that your suggestion would make it even less
likely that LP_DEAD hint bits would be set by
get_actual_variable_range() scans, because there would be no
opportunity to check the heap. Wasn't one of the goals of commit
3ca930fc39c to make it more likely that extrema values would be killed
by get_actual_variable_range() scans, for the benefit of future
get_actual_variable_range() scans?
--
Peter Geoghegan
