Re: Potential "AIO / io workers" inter-worker locking issue in PG18? - Mailing list pgsql-bugs

From Marco Boeringa
Subject Re: Potential "AIO / io workers" inter-worker locking issue in PG18?
Date
Msg-id 176b17f4-8508-4845-85b3-a0092ead7879@boeringa.demon.nl
Whole thread Raw
In response to Re: Potential "AIO / io workers" inter-worker locking issue in PG18?  (Marco Boeringa <marco@boeringa.demon.nl>)
Responses Re: Potential "AIO / io workers" inter-worker locking issue in PG18?
List pgsql-bugs
Op 20-10-2025 om 11:34 schreef Marco Boeringa:
> Hi David,
>
> To be honest I am not a SQL wizard like some of you here on the list, 
> but part of the reason I setup the query as it currently is, is that 
> the PostGIS function calls like ST_Area and ST_Perimeter can be very 
> expensive depending on the complexity and size of the geometry, and I 
> thus want to avoid at all cost to have to unnecessarily recalculate 
> them multiple times in the same query. Maybe I am misunderstanding how 
> PostgreSQL processes such queries, but I need the values multiple 
> times to calculate some other parameters. So unless PostgreSQL is 
> smart enough to cache the result and not execute ST_Area multiple 
> times if it is used multiple times in the same query, I thought it 
> wise to separate out the calculation and use the SELECT's results as 
> input for the calculation of the other parameters. Maybe that isn't 
> actually needed, but I think I remember seeing performance gains from 
> the current setup when I initially wrote it this way, but I am not 
> entirely sure at this point in time, it is a while ago. I know far to 
> little about the internals of PostgreSQL and its exact query 
> processing to say anything really sensible about this.
>
Hi David,

Looking through the 'auto_explain' output of the bad query plan, I 
noticed the below included clause as generated by the planner. In the 
context of what I actually wrote above about the desire to not run 
expensive function calls like ST_Area multiple times, do I understand it 
correctly from the 'auto_explain' output excerpt that PostgreSQL, by 
removing the self join, actually *does* run the ST_Area and ST_Perimeter 
multiple times? Is this how I need to interpret this part of the 
'auto_explain' output? If there is no caching of the function result, 
this could be expensive as well.

Marco


*** 'auto_explain' output excerpt ***:

st_area((landcover_grassy_small_scale_2_ply.way)::geography, TRUE),
st_perimeter((landcover_grassy_small_scale_2_ply.way)::geography, TRUE),
CASE
     WHEN (st_area((landcover_grassy_small_scale_2_ply.way)::geography, 
TRUE) > '0'::double PRECISION) THEN 
((power(st_perimeter((landcover_grassy_small_scale_2_ply.way)::geography, 
TRUE), '2'::double PRECISION) / 
st_area((landcover_grassy_small_scale_2_ply.way)::geography, TRUE)) / 
'12.566370614359172'::double PRECISION)
     ELSE '0'::double PRECISION
END,
st_npoints(landcover_grassy_small_scale_2_ply.way),
CASE
     WHEN (st_npoints(landcover_grassy_small_scale_2_ply.way) > 0) THEN 
(CASE
         WHEN 
(st_area((landcover_grassy_small_scale_2_ply.way)::geography, TRUE) > 
'0'::double PRECISION) THEN 
((power(st_perimeter((landcover_grassy_small_scale_2_ply.way)::geography, 
TRUE), '2'::double PRECISION) / 
st_area((landcover_grassy_small_scale_2_ply.way)::geography, TRUE)) / 
'12.566370614359172'::double PRECISION)
         ELSE '0'::double PRECISION
     END / (st_npoints(landcover_grassy_small_scale_2_ply.way))::double 
PRECISION)
     ELSE '0'::double PRECISION
END,
CASE
     WHEN (st_area((st_convexhull(t1.way))::geography, TRUE) > 
'0'::double PRECISION) THEN 
(st_area((landcover_grassy_small_scale_2_ply.way)::geography, TRUE) / 
st_area((st_convexhull(t1.way))::geography, TRUE))
     ELSE '1'::double PRECISION
END,
t1.ctid,
landcover_grassy_small_scale_2_ply.ctid,
landcover_grassy_small_scale_2_ply_pg.ctid





pgsql-bugs by date:

Previous
From: Amit Langote
Date:
Subject: Re: Segfault in RI UPDATE CASCADE on partitioned tables with LIKE+ATTACH child (attnum drift)
Next
From: "badfilez@gmail.com"
Date:
Subject: Re: PG17.6 wal apply bug (SIGSEGV)