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 opposit
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 numb
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 ma
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 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
[E
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 w
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 b
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
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?
http
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 handl
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 toke
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
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.
F
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 pa
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. T
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:
> 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.
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 optimization/preventio
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
---
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 m
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 w
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 que
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 question, has a logical break
23 matches
Mail list logo
