Speaking of pgstats
От | Magnus Hagander |
---|---|
Тема | Speaking of pgstats |
Дата | |
Msg-id | 6BCB9D8A16AC4241919521715F4D8BCEA0F8DB@algol.sollentuna.se обсуждение исходный текст |
Ответы |
Re: Speaking of pgstats
Re: Speaking of pgstats |
Список | pgsql-hackers |
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
В списке pgsql-hackers по дате отправления: