Re: Potential "AIO / io workers" inter-worker locking issue in PG18?
| От | David Rowley | 
|---|---|
| Тема | Re: Potential "AIO / io workers" inter-worker locking issue in PG18? | 
| Дата | |
| Msg-id | CAApHDvqn3JgdKxy9bba6M47fcvYacwBrrZs9s31mPmkZ1SP0Zw@mail.gmail.com обсуждение исходный текст  | 
		
| Ответ на | Re: Potential "AIO / io workers" inter-worker locking issue in PG18? (Marco Boeringa <marco@boeringa.demon.nl>) | 
| Список | pgsql-bugs | 
On Tue, 21 Oct 2025 at 11:46, Marco Boeringa <marco@boeringa.demon.nl> wrote: > I totally understood your remarks about no caching going on, and don't > intend to keep the query as-is with self join if I decide to make and > benchmark any changes. Any changes will certainly either involve a WITH > / CTE materialized, or first writing out some temporary table with the > results of the expensive function calls to be able to re-use them from > there. To get what you want, you'd need to do something like add OFFSET 0 to the subquery. That would prevent the planner from pulling it up into the main query. However, if you do that, it'll mean running those PostGIS functions on every row in the landcover_grassy_small_scale_2_ply table. You could get around that by either moving or duplicating the "t1.objectid IN (SELECT t3.objectid FROM mini_test.osm.osm_tmp_28232_ch3 AS t3)" and putting it in the WHERE clause of the subquery. David
В списке pgsql-bugs по дате отправления: