[prev in list] [next in list] [prev in thread] [next in thread] 

List:       pgsql-committers
Subject:    Re: pgsql: Compute XID horizon for page level index vacuum on primary.
From:       Peter Geoghegan <pg () bowt ! ie>
Date:       2019-03-29 16:21:27
Message-ID: CAH2-Wzm_KtysN9T=F49z6f6dh0z5vKavCwPvUY3xU0+MGyrw4Q () mail ! gmail ! com
[Download RAW message or body]

 On Fri, Mar 29, 2019 at 9:12 AM Andres Freund <andres@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


[prev in list] [next in list] [prev in thread] [next in thread]