Re: More efficient truncation of pg_stat_activity query strings

Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> On Tue, Sep 12, 2017 at 3:19 AM, Andres Freund <andres(at)anarazel(dot)de> 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 thinking
> about this problem and was wondering if we couldn't be a lot smarter
> about pg_mbcliplen(). ...

> for UTF-8, we could do that much more directly: if the string is short
> enough, stop, else, look at cmd_str[pgstat_track_activity_query_size].
> If that character has (c & 0xc0) != 0x80, write a '\0' and stop; else,
> back up until you find a character that for which that continuation
> holds, write a '\0', and stop. This kind of approach only works if we
> have a definitive test for whether something is a "continuation
> character" which probably isn't true in all encodings, but maybe it's
> still worth considering.

Offhand I think it doesn't work in anything but UTF8. A way that would
work in all encodings is to back up to the first non-high-bit-set
byte and then mbcliplen from there. Probably, there's enough ASCII
in typical SQL commands that this would often be a win.

> Your idea is probably a lot simpler to implement, though, and I
> definitely agree that shifting the work from the write side to the
> read side makes sense. Updating pg_stat_activity is a lot more common
> than reading it.

+1. I kinda doubt that it is worth optimizing further than that,
really.

regards, tom lane