Re: AIO v2.3
От | Robert Haas |
---|---|
Тема | Re: AIO v2.3 |
Дата | |
Msg-id | CA+TgmoY+D6y7X2s2cTJ3bgj1OWAAZxXTuLz78mzftPatu2bYJA@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: AIO v2.3 (Andres Freund <andres@anarazel.de>) |
Список | pgsql-hackers |
On Mon, Feb 17, 2025 at 4:01 PM Andres Freund <andres@anarazel.de> wrote: > If one instead integrates with resowners, that kind of thing works, because > exec_simple_query() calls PortalDrop(), which in turn calls > ResourceOwnerRelease(). Hmm, so maybe that's a reason to do it via resowner.c, then. The fact that it's a singleton object is a bit annoying, but you could make it not a singleton, and then either pass the relevant one to the interface functions, or store the current one in a global variable similar to CurrentMemoryContext or similar. > I guess I could just put something alongside that CommandCounterIncrement() > call, but that doesn't seem right. I guess putting it alongside the > ResourceOwnerRelease() in PortalDrop() is a bit less bad? But still doesn't > seem great. The thing that's weird about that is that it isn't really logically linked to the portal. It feels like it more properly belongs in StartTransactionCommand() / CommitTransactionCommand(). > Just using resowners doesn't seem right either, it's not really free to > register something with resowners, and for read intensive IO we can start a > *lot* of batches, so doing unnecessary work isn't great. You don't necessarily have to register a new object for every batch, do you? You could just register one and keep reusing it for the lifetime of the query. -- Robert Haas EDB: http://www.enterprisedb.com
В списке pgsql-hackers по дате отправления: