Speaking of pgstats

Поиск
Список
Период
Сортировка
От Magnus Hagander
Тема Speaking of pgstats
Дата
Msg-id 6BCB9D8A16AC4241919521715F4D8BCEA0F8DB@algol.sollentuna.se
обсуждение исходный текст
Ответы Re: Speaking of pgstats  (Tom Lane <tgl@sss.pgh.pa.us>)
Re: Speaking of pgstats  (Tom Lane <tgl@sss.pgh.pa.us>)
Список 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 по дате отправления:

Предыдущее
От: Bruno Wolff III
Дата:
Сообщение: Re: First Aggregate Funtion?
Следующее
От: Robert Treat
Дата:
Сообщение: Re: Summer of Code Preparation