On Fri, Mar 29, 2019 at 9:12 AM Andres Freund <and...@anarazel.de> wrote: > But even so, you can't have unlogged changes that you then rely on. Even > if there's no torn page issue. Currently BTP_HAS_GARBAGE and > ItemIdMarkDead() are treated as hints - if we want to guarantee all > these are accurate, I don't quite see how we'd get around WAL logging > those.
It might be possible to WAL-log the _bt_check_unique() item killing. That seems to be much more effective than the similar and better known kill_prior_tuple optimization in practice. I don't think that that should be in scope for v12, though. I for one am satisfied with your explanation. > > The code can do literally hundreds of random I/Os in an 8192 blocksize. > > What happens with 16 or 32kB? > > It's really hard to construct such cases after the sorting changes, but > obviously not impossible. But to make it actually painful you need a > workload where the implied randomness of accesses isn't already a major > bottleneck - and that's hard. There is also the fact that in many cases you'll just have accessed the same buffers from within _bt_check_unique() anyway. -- Peter Geoghegan
