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: | Raw Message | Whole Thread | 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? |