Re: domain_in performance considerations

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

In response to

Responses

Browse pgsql-hackers by date

  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)