It will be useful to show new kind of information in the trace log: number (frequency) of GEN_ID() calls which could lead to low-level contention for generators page under heavy concurrent workload.
Currently one may to see such contention in the output of fb_lock_print by analyzing data related to pending requests count.
But even when we found it, the name of problematic sequence remain unknown. The real problem is that *single* generator page contains data of hundred sequences. So, if one application decide to intensively change some "dedicated" sequence then all other connections will get influence of this activity.
Display of runtime statistics after each statement and PSQL block (proc, func, trigger) will be useful for searching of bottle-neck places in application design. This new block of statistics can be shown in form from attached picture.
Submitted by: @pavel-zotov
Attachments: trace-stat-for-number-of-gen_id-calls.png
It will be useful to show new kind of information in the trace log: number (frequency) of GEN_ID() calls which could lead to low-level contention for generators page under heavy concurrent workload. Currently one may to see such contention in the output of fb_lock_print by analyzing data related to pending requests count. But even when we found it, the name of problematic sequence remain unknown. The real problem is that *single* generator page contains data of hundred sequences. So, if one application decide to intensively change some "dedicated" sequence then all other connections will get influence of this activity. Display of runtime statistics after each statement and PSQL block (proc, func, trigger) will be useful for searching of bottle-neck places in application design. This new block of statistics can be shown in form from attached picture.