Re: Traffic jams in fn_extra

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Simon Riggs <simon(at)2ndQuadrant(dot)com>
Cc: Paul Ramsey <pramsey(at)cleverelephant(dot)ca>, Pgsql Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Traffic jams in fn_extra
Date: 2013-11-25 00:42:33
Message-ID: 13164.1385340153@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Simon Riggs <simon(at)2ndQuadrant(dot)com> writes:
> On 24 November 2013 16:02, Paul Ramsey <pramsey(at)cleverelephant(dot)ca> wrote:
>> We do the dance because its how we always have and dont know any other way, any better way. :) The usual explanation. Is there any place you can point to that demonstrates your technique?

> src/backend/utils/mmgr/README

> You can create memory contexts as children of other contexts, so for
> example you might create "PostGIS Cache Context" as a sub-context of
> TopTransactionContext. So it can be created dynamically as needed and
> will automatically go away at end of xact.

The real question of course is whether transaction-level caching is
appropriate for what they're storing. If they want only statement-level
caching then using fn_extra is often the right thing.

Also note that having the cache go away is the easy part. The hard part
is knowing whether you've created it yet in the current transaction, and
finding it if you have. The usual method is to keep a static variable
pointing to it, and plugging into the transaction cleanup callback
mechanism with a routine that'll reset the pointer to NULL at transaction
end. For examples, look for callers of RegisterXactCallback().

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Eisentraut 2013-11-25 01:23:29 Re: Building on S390
Previous Message Michael Paquier 2013-11-24 23:31:49 Re: Re[2]: [HACKERS] Connect from background worker thread to database