| From: | "Magnus Hagander" <mha(at)sollentuna(dot)net> |
|---|---|
| To: | <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Speaking of pgstats |
| Date: | 2006-04-05 20:29:21 |
| Message-ID: | 6BCB9D8A16AC4241919521715F4D8BCEA0F8DB@algol.sollentuna.se |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | 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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Robert Treat | 2006-04-05 20:35:59 | Re: Summer of Code Preparation |
| Previous Message | Bruno Wolff III | 2006-04-05 20:19:59 | Re: First Aggregate Funtion? |