| From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | Greg Stark <gsstark(at)mit(dot)edu>, pgsql-hackers(at)postgresql(dot)org |
| Subject: | parse_oper cache |
| Date: | 2009-12-26 08:53:17 |
| Message-ID: | 603c8f070912260053t505ec30fs15d230158ba976d5@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Sat, Nov 14, 2009 at 6:36 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> There's an example in parse_oper.c of a specialized cache that's about
> as complicated as this would be.
I was just taking a look at find_oper_cache_entry() and noticed
something odd. When we discover that OprCacheHash == NULL, we make
sure that CacheMemoryContext is initialized before calling
hash_create(). But since we don't pass HASH_CONTEXT to hash_create(),
ISTM it's going to use TopMemoryContext anyhow. utils/mmgr/README
indicates that the two contexts are basically equivalent anyway so I
don't think there's any visible breakage as a result of this, but it
sort of looks like an oversight.
...Robert
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Andres Freund | 2009-12-26 16:30:54 | Re: join ordering via Simulated Annealing |
| Previous Message | tomas | 2009-12-26 06:24:29 | Re: creating index names automatically? |