Tom Lane wrote: Hi,
> It would be just a small change to make the code cache the EState across > calls, saving a link to it in the FmgrInfo, but I am worried about that. > If the EState's query context is made to be a child of the memory > context containing the caller's FmgrInfo, then there is no problem as > far as memory management goes --- destroying that parent context will > make all the memory associated with the EState go away. The problem is > that an EState might have other open resources, principally buffer pins, > and there would not be any clean way to close down those resources when > the EState is no longer needed. We don't have any sort of shutdown > callback that domain_in could make use of in the general case. This is a shot in the dark, but I remember you commenting awhile back that there was a way to register a callback to be called on memory context reset or delete. I wonder if it would be possible to create a separate ResourceOwner for the EState, and save the EState in a certain memory context so that a callback would release the buffer pins or whatever. -- Alvaro Herrera http://www.CommandPrompt.com/ PostgreSQL Replication, Consulting, Custom Development, 24x7 support ---------------------------(end of broadcast)--------------------------- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
