From: | Alvaro Herrera <alvherre(at)commandprompt(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Neil Conway <neilc(at)samurai(dot)com>, pgsql-hackers(at)postgreSQL(dot)org |
Subject: | Re: domain_in performance considerations |
Date: | 2006-04-06 13:55:39 |
Message-ID: | 20060406135539.GB15753@surnet.cl |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2006-04-06 14:12:57 | Re: domain_in performance considerations |
Previous Message | Magnus Hagander | 2006-04-06 13:55:20 | Re: Windows installer bugs (was: [BUGS] BUG #2374: Installation Error) |