Re: pg_plan_advice

On Fri, Mar 27, 2026 at 4:00 AM Jakub Wartak
<jakub(dot)wartak(at)enterprisedb(dot)com> 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