Re: memory context for tuplesort return values
От | Tom Lane |
---|---|
Тема | Re: memory context for tuplesort return values |
Дата | |
Msg-id | 26061.1140730071@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: memory context for tuplesort return values (Alvaro Herrera <alvherre@commandprompt.com>) |
Ответы |
Re: memory context for tuplesort return values
|
Список | pgsql-hackers |
Alvaro Herrera <alvherre@commandprompt.com> writes: > Tom Lane wrote: >> I've been modifying tuplesort.c to keep all the sort's local data in a >> separate memory context, to simplify and speed up cleaning up the data >> during tuplesort_end. > Is it possible to make the TupleTableSlot not free the tuple > automatically? AFAIR there is a parameter to the creation routine of a > TupleTableSlot to make it so, but I don't know if it's possible to use > in tuplesort.c's case at all. The problem is that we specifically *want* the caller to free the tuple when done with it. The API is essentially that tuplesort_gettuple is passing ownership of the tuple over to the caller. Without this it seems very hard to avoid an essentially useless palloc/pfree cycle per tuple. > Maybe it is possible to write some sort of magic number to the > TupleTableSlot before it is destroyed, which could be checked if > somebody tries to destroy it again, to warn them that the code should be > changed to cope with the new order of things. Oh, the coredump is reliable enough if you compiled with MEMORY_CONTEXT_CHECKING ... we don't need any more frammishes there. regards, tom lane
В списке pgsql-hackers по дате отправления: