Re: [HACKERS] More efficient truncation of pg_stat_activity query strings

2017-09-19 Thread Andres Freund
Hi, On 2017-09-15 17:43:35 +0530, Kuntal Ghosh wrote: > The patch looks good to me. I've done some regression testing with a > custom script on my local system. The script contains the following > statement: > SELECT 'aaa..' as col; > > Test 1 > --- > duration:

Re: [HACKERS] More efficient truncation of pg_stat_activity query strings

2017-09-15 Thread Robert Haas
On Fri, Sep 15, 2017 at 4:49 PM, Andres Freund wrote: > On 2017-09-15 16:45:47 -0400, Tom Lane wrote: >> Andres Freund writes: >> > Version correcting these is attached. Thanks! >> >> I'd vote for undoing the s/st_activity/st_activity_raw/g business. >>

Re: [HACKERS] More efficient truncation of pg_stat_activity query strings

2017-09-15 Thread Andres Freund
On 2017-09-15 16:45:47 -0400, Tom Lane wrote: > Andres Freund writes: > > Version correcting these is attached. Thanks! > > I'd vote for undoing the s/st_activity/st_activity_raw/g business. > That may have been useful while writing the patch, to ensure you > found all the

Re: [HACKERS] More efficient truncation of pg_stat_activity query strings

2017-09-15 Thread Tom Lane
Andres Freund writes: > Version correcting these is attached. Thanks! I'd vote for undoing the s/st_activity/st_activity_raw/g business. That may have been useful while writing the patch, to ensure you found all the references; but it's just creating a lot of unnecessary

Re: [HACKERS] More efficient truncation of pg_stat_activity query strings

2017-09-15 Thread Andres Freund
On 2017-09-15 08:25:09 -0400, Robert Haas wrote: > On Thu, Sep 14, 2017 at 2:03 AM, Andres Freund wrote: > > Here's a patch that implements that idea. > > From the department of cosmetic nitpicking: > > + * All supported server-encodings allow to determine the length of

Re: [HACKERS] More efficient truncation of pg_stat_activity query strings

2017-09-15 Thread Robert Haas
On Thu, Sep 14, 2017 at 2:03 AM, Andres Freund wrote: > Here's a patch that implements that idea. >From the department of cosmetic nitpicking: + * All supported server-encodings allow to determine the length of a make it possible to determine + * multi-byte

Re: [HACKERS] More efficient truncation of pg_stat_activity query strings

2017-09-15 Thread Kuntal Ghosh
On Thu, Sep 14, 2017 at 11:33 AM, Andres Freund wrote: > On 2017-09-12 00:19:48 -0700, Andres Freund wrote: >> Hi, >> >> I've recently seen a benchmark in which pg_mbcliplen() showed up >> prominently. Which it will basically in any benchmark with longer query >> strings, but

Re: [HACKERS] More efficient truncation of pg_stat_activity query strings

2017-09-14 Thread Andres Freund
On 2017-09-12 00:19:48 -0700, Andres Freund wrote: > Hi, > > I've recently seen a benchmark in which pg_mbcliplen() showed up > prominently. Which it will basically in any benchmark with longer query > strings, but fast queries. That's not that uncommon. > > I wonder if we could avoid the cost

Re: [HACKERS] More efficient truncation of pg_stat_activity query strings

2017-09-12 Thread Tom Lane
Robert Haas writes: > On Tue, Sep 12, 2017 at 3:19 AM, Andres Freund wrote: >> Therefore I wonder if we couldn't just store a querystring that's >> essentially just a memcpy()ed prefix, and do a pg_mbcliplen() on the >> read side. > Interesting idea.

Re: [HACKERS] More efficient truncation of pg_stat_activity query strings

2017-09-12 Thread Robert Haas
On Tue, Sep 12, 2017 at 3:19 AM, Andres Freund wrote: > Therefore I wonder if we couldn't just store a querystring that's > essentially just a memcpy()ed prefix, and do a pg_mbcliplen() on the > read side. I think that should work because all *server side* encodings > store

Re: [HACKERS] More efficient truncation of pg_stat_activity query strings

2017-09-12 Thread Tatsuo Ishii
> Check the information the pg_*_mblen use / how the relevant encodings > work. Will be something like > int > pg_utf_mblen(const unsigned char *s) > { > int len; > > if ((*s & 0x80) == 0) > len = 1; > else if ((*s & 0xe0) == 0xc0) >

Re: [HACKERS] More efficient truncation of pg_stat_activity query strings

2017-09-12 Thread Andres Freund
On 2017-09-12 16:53:49 +0900, Tatsuo Ishii wrote: > > read side. I think that should work because all *server side* encodings > > store character lengths in the *first* byte of a multibyte character > > What do you mean? I don't see such data in a multibyte string. Check the information the

Re: [HACKERS] More efficient truncation of pg_stat_activity query strings

2017-09-12 Thread Tatsuo Ishii
> read side. I think that should work because all *server side* encodings > store character lengths in the *first* byte of a multibyte character What do you mean? I don't see such data in a multibyte string. Best regards, -- Tatsuo Ishii SRA OSS, Inc. Japan English: