Re: domain_in performance considerations - Mailing list pgsql-hackers

From Alvaro Herrera
Subject Re: domain_in performance considerations
Date
Msg-id 20060406135539.GB15753@surnet.cl
Whole thread Raw
In response to domain_in performance considerations  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: domain_in performance considerations  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
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


pgsql-hackers by date:

Previous
From: Jim Nasby
Date:
Subject: Windows installer bugs (was: [BUGS] BUG #2374: Installation Error)
Next
From: "Magnus Hagander"
Date:
Subject: Re: Windows installer bugs (was: [BUGS] BUG #2374: Installation Error)