Re: [HACKERS] Parallel bitmap heap scan
От | Dilip Kumar |
---|---|
Тема | Re: [HACKERS] Parallel bitmap heap scan |
Дата | |
Msg-id | CAFiTN-s7B=TeJahb15W-J5e3PGLkAAcPK=JSCU6RSSinETfpYg@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: [HACKERS] Parallel bitmap heap scan (Robert Haas <robertmhaas@gmail.com>) |
Ответы |
Re: [HACKERS] Parallel bitmap heap scan
|
Список | pgsql-hackers |
On Wed, Feb 8, 2017 at 3:44 AM, Robert Haas <robertmhaas@gmail.com> wrote: >>> +#ifndef SH_USE_NONDEFAULT_ALLOCATOR >>> + >> >> That should probably be documented in the file header. > > Right. OK, did that and a few other cleanups, and committed. The new SH_CREATE(MemoryContext ctx, uint32 nelements) don't have any option to supply arguments to it. Our callback functions need access to TBM. Is it expected that if the user of SH_CREATE who doesn't want to pass a "MemoryContext" then we can pass arguments instead of ctx? something like this ? if (!tbm->dsa) tbm->pagetable = pagetable_create(tbm->mcxt, 128); else tbm->pagetable = pagetable_create((MemoryContext)tbm, 128); And, In allocation function, we can access this context and typecast to tbm? As shown below. static void * pagetable_allocate(pagetable_hash *pagetable, Size size) { TIDBitmap *tbm = pagetable->ctx; So Is it expected to do like I explained above, or we missed to have an arg parameter to SH_CREATE as well as in SH_TYPE structure or there is some other way you have in mind? -- Regards, Dilip Kumar EnterpriseDB: http://www.enterprisedb.com
В списке pgsql-hackers по дате отправления: