Re: [PATCHES] [HACKERS] Overhead for stats_command_string et al, take 2

2006-06-26 Thread Tom Lane
Bruce Momjian <[EMAIL PROTECTED]> writes: > If you put a contition test in set_ps_display(), the only clean way to > do this is for init_ps_display() to force update_process_title to true > before we call set_ps_display(), then reset it to its original value, > but that sounds pretty ugly. No, ref

Re: [PATCHES] [HACKERS] Overhead for stats_command_string et al, take 2

2006-06-26 Thread Tom Lane
Bruce Momjian <[EMAIL PROTECTED]> writes: > Tom Lane wrote: >> This is an ugly patch. Why not *one* test of the GUC variable, inside >> set_ps_display(), and no side-effects on callers? You would need to >> force an initial update from init_ps_display, but that only requires a >> small amount of

Re: [PATCHES] [HACKERS] Overhead for stats_command_string et al, take 2

2006-06-26 Thread Tom Lane
Bruce Momjian <[EMAIL PROTECTED]> writes: > Attached patch adds GUC 'update_process_title' to control ps display > updates per SQL command. Default to 'on'. GUC name OK? This is an ugly patch. Why not *one* test of the GUC variable, inside set_ps_display(), and no side-effects on callers? You

Re: [PATCHES] [HACKERS] Overhead for stats_command_string et al, take 2

2006-06-26 Thread Bruce Momjian
Tom Lane wrote: > Bruce Momjian <[EMAIL PROTECTED]> writes: > > Yep, I see 8% here. I will add a patch to allow the ps display to be > > turned off. > > I think we'd still want a backend to set the PS display once with its > identification data (user/DB name and client address). It's just the >

Re: [PATCHES] [HACKERS] Overhead for stats_command_string et al, take 2

2006-06-26 Thread Bruce Momjian
Tom Lane wrote: > Bruce Momjian <[EMAIL PROTECTED]> writes: > > Seeing stats_command_string with almost zero overhead is great news! > > Should we remove that setting and just have it enabled all > > the time? > > If you don't need it, you shouldn't have to pay any overhead for it, > I think. One

Re: [PATCHES] [HACKERS] Overhead for stats_command_string et al, take 2

2006-06-26 Thread Tom Lane
Bruce Momjian <[EMAIL PROTECTED]> writes: > Tom Lane wrote: >> Something that might also be interesting is an option to suppress >> per-command ps_status reporting. On machines where updating ps status >> takes a kernel call, there's now a pretty good argument why you might >> want to turn that of

Re: [PATCHES] [HACKERS] Overhead for stats_command_string et al, take 2

2006-06-26 Thread Tom Lane
I wrote: > IIRC, newer BSDen use a kernel call for this, so you should be able to > measure it on your own machine. Just tweak ps_status.c to force it to > select PS_USE_NONE instead of PS_USE_SETPROCTITLE to generate a > comparison case. I'll try it on my old HPUX box too. On HPUX, I get a medi