Bruce Momjian <maillist@candle.pha.pa.us> writes:
> We can use setproctitle/sendmail hack to change the process
> name from postmaster to postgres, but are these sufficiently quick to
> be run for every query to display the query type, i.e. SELECT.
That's something I'm a little worried about too. The sendmail code
offers these implementation strategies for setproctitle:
#define SPT_NONE 0 /* don't use it at all */
#define SPT_REUSEARGV 1 /* cover argv with title information */
#define SPT_BUILTIN 2 /* use libc builtin */
#define SPT_PSTAT 3 /* use pstat(PSTAT_SETCMD, ...) */
#define SPT_PSSTRINGS 4 /* use PS_STRINGS->... */
#define SPT_SYSMIPS 5 /* use sysmips() supported by NEWS-OS 6 */
#define SPT_SCO 6 /* write kernel u. area */
#define SPT_CHANGEARGV 7 /* write our own strings into argv[] */
It looks like our existing code in postgres.c corresponds to the last
of these (CHANGEARGV). REUSEARGV and PSSTRINGS are variants on this
with probably not much worse performance. PSTAT is a kernel call,
while the SCO method involves lseek and write on /dev/kmem --- at least
two kernel calls, and likely it doesn't even work without special privs.
BUILTIN means use libc's setproctitle, and SYSMIPS calls some other libc
subroutine. The performance of those two methods is indeterminate, but
probably the library routines turn around and do one of these same
sorts of things.
I'm inclined to think that another kernel call per SQL statement is
not something to be overly worried about, but maybe you see it
differently.
Here's a thought: we could implement an additional function, say
"fast_setproctitle", which is defined to do nothing unless the
setproctitle implementation strategy is one we know to be fast.
Then we'd use the regular setproctitle to set up the initial
"postgres user database" display, and call fast_setproctitle to
munge the display (or not) for each statement. This would have the
additional hack value that it would be easy for a particular
installation to override our choice about whether updating the
process title for every statement is worthwhile.
regards, tom lane
