Re: [HACKERS] Parallel bitmap heap scan
От | Robert Haas |
---|---|
Тема | Re: [HACKERS] Parallel bitmap heap scan |
Дата | |
Msg-id | CA+TgmoY5LQeHMv-DisVeD_1ZbLc1vOSCFb2=nnZjHE8G0Yh9Bg@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: [HACKERS] Parallel bitmap heap scan (Dilip Kumar <dilipbalaut@gmail.com>) |
Список | pgsql-hackers |
On Wed, Feb 8, 2017 at 1:59 AM, Dilip Kumar <dilipbalaut@gmail.com> wrote: > IIUC, tbm_prepare_shared_iterate will be called only by the leader, > for tbmiterator as well as for the prefetch_iterator. And, > tbm_attach_shared_iterate will be called by each backend and for both > the iterators. That's what I had in mind. > IMHO, tbm_attach_shared_iterate should return TBMIterator with > reference to TBMSharedIterator inside it. The reason behind same is > that we can not keep TBMIterateResult inside TBMSharedIterator > otherwise, results will also go in shared memory but we want to have > local result memory for each worker so that other worker doesn't > disturb it. No, I don't agree. I think TBMSharedIterator should be an unshared structure created by tbm_attach_shared_iterate, which can internally contain backend-private state like a TBMIterateResult, and which can also contain a pointer to the shared-memory structure previously created by tbm_prepare_shared_iterate. That thing needs to be called something other than a TBMSharedIterator, like TBMSharedIterationState or something. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
В списке pgsql-hackers по дате отправления: