Maksim Milyutin

> Может ли быть такое, что работает не правильно из-за того, что процесс `VACUUM ANALYZE convead.visitors;` ещё не завершился? Таблица была порядка 150 Gb и он идёт уже 4+ часа...

> VACUUM прошёл, ситуация в целом немного изменилась: теперь команда `select set_enable_parent('visitors', false)` действительно меняет поведение и планировщик начинает смотреть только в нужную партицию, но когда я это делаю, начинают...

Hi @jamessewell ! > It is set Yes, I saw later so removed my last post > I occasionally get a queryid listed. For example the SELECT from the wait...

Hi @jamessewell ! Sorry for so delayed answer. The core issue here is that the lock acquiring on relations happens on parse-analyze stage when database objects in query is transformed...

In general, due to much of locks on relations and other db objects are acquired in parse-analyze routine there is no ability to assign queryId values to the waits on...

In general, with current state of lock acquiring mechanics it's possible to assign queryId value to the waiting on heavyweight locks. But this assignment will be deferred. And it would...

This issue is consequence that queryId is set for upper-level query but cleared by the first completed subquery. > Should pg_wait_sampling track nesting level like pg_stat_statements does? Yeah, definitely in...

Thanks for explanation and notes. > the planner can run some queries but I don't think those can be parallel Could you provide an example of such behavior? AFAIK, as...

> The problem is that the parallel worker can itself be a worker for a query at any sublevel. So you may know that the worker is itself nesting execution,...

> The problem is that the parallel worker can itself be a worker for a query at any sublevel. So you may know that the worker is itself nesting execution,...