Heikki Linnakangas wrote:
> On 06/04/18 01:59, Claudio Freire wrote:
> > The iteration interface, however, seems quite specific for the use
> > case of vacuumlazy, so it's not really a good abstraction.
>
> Can you elaborate? It does return the items one block at a time. Is that
> what you mean by being specific for vacuumlazy? I guess that's a bit
> special, but if you imagine some other users for this abstraction, it's
> probably not that unusual. For example, if we started using it in bitmap
> heap scans, a bitmap heap scan would also want to get the TIDs one block
> number at a time.
FWIW I liked the idea of having this abstraction possibly do other
things -- for instance to vacuum brin indexes you'd like to mark index
tuples as "containing tuples that were removed" and eventually
re-summarize the range. With the current interface we cannot do that,
because vacuum expects brin vacuuming to ask for each heap tuple "is
this tid dead?" and of course we don't have a list of tids to ask for.
So if we can ask instead "how many dead tuples does this block contain?"
brin vacuuming will be much happier.
> Looking at the changes to the regression test in this, I don't quite
> understand what it's all about. What are the "wait_barriers" for? If I
> understand correctly, they're added so that the VACUUMs can remove the
> tuples that are deleted in the test. But why are they needed now? Was that
> an orthogonal change we should've done anyway?
>
> Rather than add those wait_barriers, should we stop running the 'vacuum'
> test in parallel with the other tests? Or maybe it's a good thing to run it
> in parallel, to test some other things?
20180207235226.zygu4r3yv3yfcnmc@alvherre.pgsql
--
Álvaro Herrera https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services