On Fri, Mar 27, 2026 at 4:00 AM Jakub Wartak <[email protected]> wrote: > there is visible collapse from 190k to 48k tps was due to constant flood > of artificial calls of: select count(*) from pg_get_collected_shared_advice(); > > The code does LW_SHARED there over potentially lots of of > tuplestore_putvalues() > calls. However any other backend does pgca_planner_shutdown()-> > pg_collect_advice_save()->store_shared_advice() which is trying to grab > LW_EXCLUSIVE lock, so everything might be be blocked across whole cluster? (I > mean for the duration of tuplestore entry and that seems to even talk about > "tape"/"disk", so to me it looks like prolonged I/O operations for temp might > impact CPU-only planning stuff?)
Yeah ... I mean, I don't know what you want here. If you fetch very large quantities of data under a shared lock while concurrent activity is trying to add data under an exclusive lock, that's going to be slow. Now, as you say, there are ways to improve this. However, I don't feel like running pg_get_collected_shared_advice() in a tight loop is a normal use case. Normally you would turn it on, run a bunch of queries, and then run that once at the end. Even that could hit some issues because every session will be fighting to insert into the hash table, but here you've made it much worse in a way that I would say is artificial. > 0004: question, why in the pg_get_advice_stashes() the second call to > dshash_seq_init() nearby "Emit results" is done with exclusive=true , but > apparently only reads it? Good question. Actually, couldn't both of those loops use a shared lock only? -- Robert Haas EDB: http://www.enterprisedb.com
