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 (pgsql-hackers@postgresql.org)
To make changes to your subscription:

Reply via email to