On Fri, Mar 27, 2026 at 1:00 AM Jakub Wartak <[email protected]> wrote: > > On Thu, Mar 26, 2026 at 6:20 PM Robert Haas <[email protected]> wrote: > >[..v23] > > 0003: please be the judge here, as I'm not sure. Isn't there some too high > concurrency hit in pg_get_collected_shared_advice? If I do
I've been thinking more about 0003 (pg_collect_advice) today, and I'm getting increasingly skeptical that we should try to get that into 19. It just feels like there is more design work to be done here, and I don't see the pressing need to have this in place. Instead, I wonder if we should just add a "debug_log_plan_advice" setting to pg_plan_advice, that always logs the plan advice when enabled. Basically like "always_store_advice_details", but emit a log line in addition to doing the work. That could either be enabled on a single session with a sufficiently high client_min_messages to consume it directly, or written to the log for a few minutes when trying to capture production activity (on small production systems where the logging overhead is acceptable). I don't see a log-based approach be less useful than the shared memory approach, because I think our aggregation design here is not right yet (and doesn't scale to production traffic), and so we might as well have the community try out some things with the log output instead. For the other one 0004 (pg_stash_advice) I feel its worth trying to get it in, if we can figure out the remaining issues. I'll try to do another pass on that tomorrow after some sleep. Thanks, Lukas -- Lukas Fittl
