While we're talking about pgstats... There was some talk a while back
about the whole bufferer/collector combination perhaps being unnecessary
as well, and that it might be a good idea to simplify it down to just a
collector. I'm not 100% sure what the end result of that discussion was,
thouhg, and I can't find it in the archives :-(
Anyway. I think this might help some of the win32 specific issues.
Considering we had a lot of problems getting it up and running, most
related to the "socket inheritance across two fork/exec steps", I still
think there might be problems lurking there that would simply go away in
a case like this. The overhead is also definitly larger on win32,
considering a process taskswitch is much more expensive, and considering
that we emulate the pipe using TCP...
So I'd be interested in giving this a shot, but before starting I'd like
to know if people think it's a worthwhile thing, or if it's likely to be
rejected out-of-hand. (Of course, it can always be rejected on
ipmlementation details, or on the fact that it wasn't a good idea, but
if it's already known that it's not a good idea I don't want to spend
time on it..)
The general idea would be to still use UDP backend->stats but get rid of
the pipe part (emulated by standard tcp sockets on win32), so we'd still
have the "lose packets instead of blocking when falling behind".
//Magnus
---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match
