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 | CAApHDvqiZ_VyLcSiDJMZwk4pJkwjwEszQ+7C98x2QfAL0nF=4w@mail.gmail.com обсуждение исходный текст  | 
		
| Ответ на | Re: Potential "AIO / io workers" inter-worker locking issue in PG18? (Marco Boeringa <marco@boeringa.demon.nl>) | 
| Ответы | 
                	
            		Re: Potential "AIO / io workers" inter-worker locking issue in PG18?
            		
            		 | 
		
| Список | pgsql-bugs | 
On Tue, 21 Oct 2025 at 10:57, Marco Boeringa <marco@boeringa.demon.nl> wrote: > PostGIS functions can be very expensive, especially in the context of > the fact that Polygon and Line geometries can vary vastly in size in > terms of the number of vertices that constitute them, which has a > profound impact on some PostGIS function calls, merely due to the > enormous complexity of some shapes. How expensive the function call is is irrelevant as there simply is no function result caching going on and there's nothing wired up in any released version of PostgreSQL which gives you this with the query you've written. You still seem to be under the illusion that the self-join is giving you some sort of caching. If you remain content in not trusting me on that, by all means, create a plpgsql function with a RAISE NOTICE and try it out for yourself. > But of course you're right that any change will need some thorough > testing before assuming it will actually benefit the queries. I don't recall talking about testing... (It may help if you quote things you're replying to. This conversation will be quite hard to follow with your top post replies.) This whole conversation has drifted well off what the original report was about, so I think it's better if you need more help on this to use pgsql-performance@lists.postgresql.org David
В списке pgsql-bugs по дате отправления: