Mike Blackwell <mike.blackw...@rrd.com> writes: > On Sun, Jul 17, 2016 at 10:34 AM, Tom Lane <t...@sss.pgh.pa.us> wrote: >> It occurs to me that we could also remove the update_process_title GUC: >> what you would do is configure a process_title pattern that doesn't >> include the %-escape for current command tag, and the infrastructure >> could notice that that escape isn't present and skip unnecessary updates. >> The same kind of trick could be used for other potentially-expensive >> items like the lock "waiting" flag.
> This seems like an interesting project for learning my way around gucs and > logging. âCould you elaborate a little > on the cost considerations? Well, the point is to avoid unnecessary updates of the process title, since on many platforms that involves a kernel call. Most of the fields that you might want in it are static anyhow, but current command tag obviously changes often, as does the lock-waiting annotation. The idea would be to notice that the selected title string doesn't call for those fields and skip updates if so. I envision this as having assignment of the process_title GUC compute a bitmask showing which possibly-mutable escape codes appear in the string (this could be implemented by having the check_hook compute a bitmask and save it via the GUC "extra" mechanism). Then calls to set_ps_display could be extended with a bitmask parameter showing which field types are known to be changing in that call, and you just "AND" to discover if an update is needed. regards, tom lane -- Sent via pgsql-hackers mailing list (email@example.com) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers