Re: BUG #13484: Performance problem with logical decoding

On 2015-07-06 22:56:22 +0200, olivier(dot)gosseaume(at)free(dot)fr wrote:
> >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...

> >> What is observe is that the spilling occurs, and
> >> when the .snap file is created then pg_recvlogical will consume data
> >> but it does take a long time exactly the same time as
> >> pg_logical_slot_get_changes in fact.
> >
> >Another possibility is that there's some windows specific problem here.
>
> I do agree. It must be a Windows issue then. I reproduced it on two
> differents dev machines both with SSD and Windows 7. I can make a try
> on a real Windows 2008 or 2012 server with SAN access just to
> check. Will do it tomorrow

Any chance you could cross check on a unixoid OS? Just to rule out it's
not some configuration/setup/? issue?

Regards,

Andres