RE: Parallel heap vacuum - Mailing list pgsql-hackers

From Hayato Kuroda (Fujitsu)
Subject RE: Parallel heap vacuum
Date
Msg-id TYAPR01MB56929B3F62DE14C4FD6210FCF53E2@TYAPR01MB5692.jpnprd01.prod.outlook.com
Whole thread Raw
In response to Re: Parallel heap vacuum  (Tomas Vondra <tomas@vondra.me>)
List pgsql-hackers
Dear Tomas,

> 1) I really like the idea of introducing "compute_workers" callback to
> the heap AM interface. I faced a similar issue with calculating workers
> for index builds, because right now plan_create_index_workers is doing
> that the logic works for btree, but really not brin etc. It didn't occur
> to me we might make this part of the index AM ...

+1, so let's keep the proposed style. Or, can we even propose the idea
to table/index access method API?
I've considered bit and the point seemed that which arguments should be required.

> 4) I think it would be good to have some sort of README explaining how
> the parallel heap vacuum works, i.e. how it's driven by FSM. Took me a
> while to realize how the workers coordinate which blocks to scan.

I love the idea, it is quite helpful for reviewers like me.

Best regards,
Hayato Kuroda
FUJITSU LIMITED


pgsql-hackers by date:

Previous
From: Richard Guo
Date:
Subject: Re: Wrong results with right-semi-joins
Next
From: Peter Smith
Date:
Subject: Re: Introduce XID age and inactive timeout based replication slot invalidation