On 11/8/2004 5:32 PM, Tom Lane wrote:
Another relevant question is why you are expecting to get this
information through pgstats and not by looking in the postmaster log.
The pgstats were originally designed to give hints for tuning. That's
why they cover cache hits vs. misses per table and
Simon Riggs [EMAIL PROTECTED] writes:
My intention was towards a data warehouse situation, and my comments are
only relevant in that context. Possibly 25+% of the user base use this
style of processing. In that case, I expect queries to run for minutes
or hours.
I come from the opposite
Josh Berkus wrote:
Tom,
Another relevant question is why you are expecting to get this
information through pgstats and not by looking in the postmaster log.
I don't know about you, but I don't have any tools that are designed to
cope nicely with looking at tables that have columns that might be
Tom Lane wrote:
Greg Stark [EMAIL PROTECTED] writes:
What do you think is broken about fragmented UDP packets?
Fragmentation happens at the IP protocol level, the kernel is responsible for
reassembly. There's nothing for the application level to handle.
And, by the same token, on platforms
Tom Lane [EMAIL PROTECTED] writes:
Greg Stark [EMAIL PROTECTED] writes:
What do you think is broken about fragmented UDP packets?
Fragmentation happens at the IP protocol level, the kernel is responsible
for
reassembly. There's nothing for the application level to handle.
And, by
Greg Stark [EMAIL PROTECTED] writes:
The pgstat messages are indeed fixed size.
No, there's a fixed maximum size.
regards, tom lane
---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?
Tom Lane [EMAIL PROTECTED] writes:
Greg Stark [EMAIL PROTECTED] writes:
The pgstat messages are indeed fixed size.
No, there's a fixed maximum size.
Hm. *rereads source*
It's true, pgstat_report_activity only sends the actual size of the query, not
the full payload size.
The only problem
Greg Stark [EMAIL PROTECTED] writes:
The only problem I see in raising the size of PGSTAT_MSG_PAYLOAD is that it
also governs the size of PGSTAT_NUM_TABPURGE and PGSTAT_NUM_TABENTRIES.
There's no need to grow those arrays and risk losing them. But these message
sizes could just be left based
Greg Stark [EMAIL PROTECTED] writes:
That would have no downside and only benefits. The worst case is that a
machine that didn't handle UDP fragment reassembly would drop the packets that
postgres is currently dropping preemptively.
Huh? We're not dropping the query *entirely*, which is what
Tom Lane wrote:
It's really a
performance issue: do you want to pay the penalty associated with
reassembling messages that exceed the loopback MTU [...]
BTW, the loopback MTU here is quite large:
[EMAIL PROTECTED]:~$ /sbin/ifconfig lo | grep MTU
UP LOOPBACK RUNNING MTU:16436 Metric:1
Tom,
Another relevant question is why you are expecting to get this
information through pgstats and not by looking in the postmaster log.
I don't know about you, but I don't have any tools that are designed to
cope nicely with looking at tables that have columns that might be many
K wide.
Tom Lane [EMAIL PROTECTED] writes:
I'd vote in favour of relaxing the limit entirely, as Sean suggests.
The choice is not between limit and no limit, it is between
limit and broken.
What do you think is broken about fragmented UDP packets?
Once Upon a Time fragmented UDP packets
Simon Riggs [EMAIL PROTECTED] writes:
On Sun, 2004-11-07 at 20:59, Greg Stark wrote:
What do you think is broken about fragmented UDP packets?
...probably that pgstat.c doesn't handle them at all, so if they occur
then you've lost data. Until that is fixed, we have a limit.
Greg Stark [EMAIL PROTECTED] writes:
What do you think is broken about fragmented UDP packets?
Fragmentation happens at the IP protocol level, the kernel is responsible for
reassembly. There's nothing for the application level to handle.
And, by the same token, on platforms where it is broken
Sean Chittenden wrote:
Is there any reason the length of
pg_catalog.pg_stat_activity.current_query is capped at 255 characters?
Why can't it be a pointer to the currently running query?
Seems silly to me and is a PITA to try and use as a debugging tool only
to find out that the query in
Sean Chittenden [EMAIL PROTECTED] writes:
Is there any reason the length of
pg_catalog.pg_stat_activity.current_query is capped at 255 characters?
The reason for a limit is to avoid fragmentation of UDP messages.
I believe we've set it at 1K for 8.0, though, and if you are on
a platform with
Is there any reason the length of
pg_catalog.pg_stat_activity.current_query is capped at 255 characters?
The reason for a limit is to avoid fragmentation of UDP messages.
I believe we've set it at 1K for 8.0, though, and if you are on
a platform with a higher message size limit you could raise it
Sean Chittenden [EMAIL PROTECTED] writes:
I'm confused... UDP as in the UDP/IP? RPC caps UDP messages at 8K and
NFS over UDP often runs at 32K... where is UDP used in the backend?
pgstat messages travel over UDP/IP.
regards, tom lane
I'm confused... UDP as in the UDP/IP? RPC caps UDP messages at 8K and
NFS over UDP often runs at 32K... where is UDP used in the backend?
pgstat messages travel over UDP/IP.
Over the loopback interface, right? Then why worry about
fragmentation? This seems like premature
Sean Chittenden [EMAIL PROTECTED] writes:
Would you be open to increasing this further after the 8.0 release?
Nope.
I haven't heard of anyone complaining about dropped/fragmented pgstat
messages. :) -sc
That's because we keep 'em small enough to not fragment.
Simon Riggs [EMAIL PROTECTED] writes:
Not having the whole query is painful. Raising it to 1K doesn't get
round the fact that it's the longer queries that tend to be the more
painful ones, and so they are the ones you want to trap in full and
EXPLAIN, so you can find out if they are *ever*
Sean Chittenden [EMAIL PROTECTED] writes:
Having a 1K query isn't uncommon on some of the stuff I work on, an 8K
query...
that's a tad different and would stick out like a sore thumb.
Just as a point of reference, I've been processing my logs to see how large my
queries work out to. They
22 matches
Mail list logo
