Parece claro que definir synchronous_commit OFF em sessões - nas quais a desvantagem super rara (transações supostamente confirmadas sendo perdidas em caso de falha do servidor) - é bom, aumenta o desempenho dessas sessões, pois elas não precisam esperar pelo WAL para ser descarregado no disco.
No entanto, o que não consigo entender é como isso afeta todas as sessões que são confirmadas na mesma janela de tempo que possuem arquivos synchronous_commit ON.
Entendo que as sessões que produzem synchronous_commit OFFtanto WAL quanto aquelas que o possuem ON(ou até mais, pois realizam mais tarefas ao mesmo tempo, já que não precisam esperar pelo WALWrite). Então as sessões que possuem ONserão tão lentas como se todas as sessões tivessem ON?
Cenário 1: 10 sessões fazendo DML pesado ONe 10 sessões que o possuem OFF.
Cenário 2: 20 sessões fazendo DML pesado que possui ON.
O que eu acho que acontece: no cenário 1, as 10 sessões OFFproduzem ainda mais WAL do que no cenário 2, portanto as sessões ONaguardam ainda mais no WALWrite do que no cenário 1.
Estou entendendo certo que cada commit sempre espera que TODOS os dados WAL atuais ( xid<= own xid) sejam gravados, não apenas os dados 'ITS OWN' do WAL?
Você está assumindo que as sessões têm uma quantidade infinita de trabalho a fazer. De modo mais geral, uma sessão tem uma tarefa específica a realizar e, uma vez concluída, está concluída. Ele não vai inventar novas tarefas só porque terminou a original mais cedo.
Você fez benchmark e viu? Dependerá de coisas como seu sistema de armazenamento e do tamanho de cada transação.
Seu entendimento está correto, mas as implicações provavelmente não estão. Geralmente o gargalo não está no número de bytes do WAL gravados, mas na espera pela confirmação de que todos os dados chegaram com segurança à mídia estável. Escrever e liberar um determinado número de bytes em 10 blocos será menos trabalhoso (e menos tempo) do que escrever e liberar o mesmo número de bytes em 20 blocos, a menos que esse número de bytes seja muito grande.
Se eu estiver liberando de forma síncrona, mas acontecer de não estar pronto para começar até logo depois que outra pessoa iniciou a descarga, não poderei iniciar minha descarga até que a descarga termine. Embora se eles fossem assíncronos, posso iniciar minha liberação (que incluirá os dados deles e os meus) imediatamente após ficar pronto e, assim, terminar mais cedo.