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: 30
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.
>> That may have been useful while writing the
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 references; but it's ju
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
delta in the final code,
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 a
>
> make it possib
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 character from it's first by
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 fast queries. That's
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 of
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. I was (ha, ha, what a coincidence) also thin
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 character lengths in t
> 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)
>
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 pg_*
> 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: http://www.sraoss.co.jp/index
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 of pg_mbcliplen() from within
pgstat_report_activity(), by moving s
14 matches
Mail list logo
