On 1/2/2006 3:20 PM, Tom Lane wrote:
[ moving to -hackers ]
Bruce Momjian <pgman@candle.pha.pa.us> writes:
I did some research on this because the numbers Tom quotes indicate there
is something wrong in the way we process stats_command_string
statistics.
[ ... proposed patch that seems pretty klugy to me ... ]
I wonder whether we shouldn't consider something more drastic, like
getting rid of the intermediate stats buffer process entirely.
The original design for the stats communication code was based on the
premise that it's better to drop data than to make backends wait on
The original design was geared towards searching for useless/missing
indexes and tuning activity like that. This never happened, but instead
people tried to use it as a reliable debugging or access statistics aid
... which is fine but not what it originally was intended for.
So yes, I think looking at what it usually is used for, a message
passing system like SysV message queues (puke) or similar would do a
better job.
Jan
the stats collector. However, as things have turned out I think this
notion is a flop: the people who are using stats at all want the stats
to be reliable. We've certainly seen plenty of gripes from people who
are unhappy that backend-exit messages got dropped, and anyone who's
using autovacuum would really like the tuple update counts to be pretty
solid too.
If we abandoned the unreliable-communication approach, could we build
something with less overhead?
regards, tom lane
--
#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#================================================== [EMAIL PROTECTED] #
---------------------------(end of broadcast)---------------------------
TIP 4: Have you searched our list archives?
http://archives.postgresql.org
