>> >Are you stopping pg_recvlogical between the runs, or are you letting it
>> >run? The point of using it is that it's a streaming, i.e. that you do
>> >not need to pay to "startup" costs of logical decoding, which can be
>> >noticeable.
>>
>> No, I just let it run. In my case the bottleneck seems to be on server
>> side when spilling to disk. I can see the server build the files but
>> very slowly.
>
>That's odd. It's really just a plain series of writes. I wonder if for
>some reason windows disables write buffering or such?
>
>Ugh, I have a theory. I guess you can't easily recompile postgres with a
>patch and test again? I don't have access to windows...
Thanks for your finding. I can try to recompile on Windows (will look how). In fact I did a test with a tool called
"APIMonitor" which displays all Windows API calls during postgres execution. What I see is :
- approx 8000 writes
- for each individual write I see a call to FlushFileBuffers() which is very bad for performance, so it is a Windows
onlyissue
>Any chance you could cross check on a unixoid OS? Just to rule out it's
>not some configuration/setup/? issue?
I can try in a virtualbox, but I would prefer to test your patch before if possible
br
Olivier