From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Alvaro Herrera <alvherre(at)commandprompt(dot)com> |
Cc: | pgsql-hackers(at)postgreSQL(dot)org |
Subject: | Re: memory context for tuplesort return values |
Date: | 2006-02-23 21:27:51 |
Message-ID: | 26061.1140730071@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Alvaro Herrera <alvherre(at)commandprompt(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Alvaro Herrera | 2006-02-23 21:52:37 | Re: memory context for tuplesort return values |
Previous Message | Alvaro Herrera | 2006-02-23 21:21:59 | Re: memory context for tuplesort return values |