| From: | Paul Ramsey <pramsey(at)cleverelephant(dot)ca> |
|---|---|
| To: | Simon Riggs <simon(at)2ndquadrant(dot)com> |
| Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Pgsql Hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Traffic jams in fn_extra |
| Date: | 2013-11-24 21:02:51 |
| Message-ID: | F68F558CBDD94E378E0F3909DFD2882A@cleverelephant.ca |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
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, November 24, 2013 at 8:21 AM, Simon Riggs wrote:
> On 19 November 2013 23:08, Paul Ramsey <pramsey(at)cleverelephant(dot)ca (mailto:pramsey(at)cleverelephant(dot)ca)> 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 other 0.1% of times two things. In
> > our own GenericCacheCollection, we just statically allocate 16 slots.
>
>
>
> 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.
>
> --
> Simon Riggs http://www.2ndQuadrant.com/
> PostgreSQL Development, 24x7 Support, Training & Services
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Pavel Stehule | 2013-11-24 21:18:20 | review: create if not exists |
| Previous Message | Pavel Stehule | 2013-11-24 19:28:14 | Re: Re: [BUGS] BUG #7873: pg_restore --clean tries to drop tables that don't exist |