On Sun, Nov 24, 2013 at 4:21 PM, Simon Riggs wrote:
> Why do you need to do this dance with fn_extra?
>
> It's possible to allocate a hash table in a Transaction-lifetime
> memory context on first call into a function then cache things there.
>
fn_extra gives a handle per function call site.
It
On Sunday, November 24, 2013 at 4:42 PM, Tom Lane wrote:
> 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.
I'm not certain it is... we get some grea
Simon Riggs writes:
> On 24 November 2013 16:02, Paul Ramsey 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/RE
On 24 November 2013 16:02, Paul Ramsey wrote:
> We do the dance because it’s how we always have and don’t 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
Hi Simon,
We do the dance because it’s how we always have and don’t know any other way,
any better way. :) The usual explanation. Is there any place you can point to
that demonstrates your technique?
Thanks!
P
--
Paul Ramsey
http://cleverelephant.ca/
http://postgis.net/
On Sunday, Novem
On 19 November 2013 23:08, Paul Ramsey wrote:
> On the solution, I wasn't suggesting another void* slot, but rather a
> slot that holds a hash table, so that an arbitrary number of things
> can be stuffed in. Overkill, really, since in 99.9% of times only one
> thing would be in there, and in the
On Tue, Nov 19, 2013 at 7:32 PM, Tom Lane wrote:
> Paul Ramsey writes:
>> As we've added different kinds of caching, in our own project, we've banged
>> up against problems of multiple functions trying to stuff information into
>> the same pointer, and ended up putting an extra container of our
Paul Ramsey writes:
> As we've added different kinds of caching, in our own project, we've banged
> up against problems of multiple functions trying to stuff information into
> the same pointer, and ended up putting an extra container of our own into
> fn_extra, to hold the different kinds of s
As an extension with a lot of CPU load, we (postgis) tend to use
flinfo->fn_extra a lot, for caching things that are intensive to calculate at
the start of a query and reuse throughout subsequent functions calls.
- coordinate projection objects
- indexes of the edges of large geometries
- other
