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:
http://www.postgresql.org/mailpref/pgsql-hackers
