On 2015-07-06 22:56:22 +0200, olivier.gosseaume@free.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