From: | David Rowley <dgrowleyml(at)gmail(dot)com> |
---|---|
To: | Marco Boeringa <marco(at)boeringa(dot)demon(dot)nl> |
Cc: | Andres Freund <andres(at)anarazel(dot)de>, pgsql-bugs(at)lists(dot)postgresql(dot)org, Thom Brown <thom(at)linux(dot)com> |
Subject: | Re: Potential "AIO / io workers" inter-worker locking issue in PG18? |
Date: | 2025-10-21 00:44:52 |
Message-ID: | CAApHDvqn3JgdKxy9bba6M47fcvYacwBrrZs9s31mPmkZ1SP0Zw@mail.gmail.com |
Views: | Whole Thread | Raw Message | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
On Tue, 21 Oct 2025 at 11:46, Marco Boeringa <marco(at)boeringa(dot)demon(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Amit Langote | 2025-10-21 01:28:22 | Re: Segfault in RI UPDATE CASCADE on partitioned tables with LIKE+ATTACH child (attnum drift) |
Previous Message | Marco Boeringa | 2025-10-20 22:46:40 | Re: Potential "AIO / io workers" inter-worker locking issue in PG18? |