On Thu, Dec 5, 2019 at 10:52 AM Amit Kapila <amit.kapil...@gmail.com> wrote: > > On Thu, Dec 5, 2019 at 1:41 AM Robert Haas <robertmh...@gmail.com> wrote: > > > > On Mon, Dec 2, 2019 at 2:26 PM Masahiko Sawada > > <masahiko.saw...@2ndquadrant.com> wrote: > > > It's just an example, I'm not saying your idea is bad. ISTM the idea > > > is good on an assumption that all indexes take the same time or take a > > > long time so I'd also like to consider if this is true even in > > > production and which approaches is better if we don't have such > > > assumption. > > > > I think his idea is good. You're not wrong when you say that there are > > cases where it could work out badly, but I think on the whole it's a > > clear improvement. Generally, the indexes should be of relatively > > similar size because index size is driven by table size; it's true > > that different AMs could result in different-size indexes, but it > > seems like a stretch to suppose that the indexes that don't support > > parallelism are also going to be the little tiny ones that go fast > > anyway, unless we have some evidence that this is really true. I also > > wonder whether we really need the option to disable parallel vacuum in > > the first place. > > > > I think it could be required for the cases where the AM doesn't have a > way (or it is difficult to come up with a way) to communicate the > stats allocated by the first ambulkdelete call to the subsequent ones > until amvacuumcleanup. Currently, we have such a case for the Gist > index, see email thread [1]. >
oops, I had referred to a couple of other discussions in my reply but forgot to mention the links, doing it now. [1] - https://www.postgresql.org/message-id/CAA4eK1LGr%2BMN0xHZpJ2dfS8QNQ1a_aROKowZB%2BMPNep8FVtwAA%40mail.gmail.com [2] - https://www.postgresql.org/message-id/CAA4eK1J-VoR9gzS5E75pcD-OH0mEyCdp8RihcwKrcuw7J-Q0%2Bw%40mail.gmail.com [3] - https://www.postgresql.org/message-id/20191106022550.zq7nai2ct2ashegq%40alap3.anarazel.de -- With Regards, Amit Kapila. EnterpriseDB: http://www.enterprisedb.com