Hi, On 2023-01-11 22:30:42 +0100, Tomas Vondra wrote: > On 1/11/23 21:58, Andres Freund wrote: > > If you're thinking of decoding changes in parallel (rather than streaming > > out > > large changes before commit when possible), you'd only be able to do that in > > cases when transaction haven't performed catalog changes, I think. In which > > case there'd also be no issue wrt transactional sequence changes. > > > > Perhaps, although it's not clear to me how would you know that in > advance? I mean, you could start decoding changes in parallel, and then > you find one of the earlier transactions touched a catalog.
You could have a running count of in-progress catalog modifying transactions and not allow parallelized processing when that's not 0. > Bu maybe I misunderstand what "decoding" refers to - don't we need the > snapshot only in reorderbuffer? In which case all the other stuff could > be parallelized (not sure if that's really expensive). Calling output functions is pretty expensive, so being able to call those in parallel has some benefits. But I don't think we're there. > Anyway, all of this is far out of scope of this patch. Yea, clearly that's independent work. And I don't think relying on commit order in one more place, i.e. for sequences, would make it harder. Greetings, Andres Freund