On Tue, Mar 7, 2017 at 11:09 AM, Dilip Kumar <dilipbal...@gmail.com> wrote: > On Tue, Mar 7, 2017 at 9:34 PM, Robert Haas <robertmh...@gmail.com> wrote: >> >> + if (DsaPointerIsValid(node->pstate->tbmiterator)) >> + tbm_free_shared_area(dsa, node->pstate->tbmiterator); >> + >> + if (DsaPointerIsValid(node->pstate->prefetch_iterator)) >> + dsa_free(dsa, node->pstate->prefetch_iterator); > > As per latest code, both should be calling to tbm_free_shared_area > because tbm_free_shared_area is capable of handling that. My silly > mistake. I will fix it.
Thanks. I don't think I believe this rationale: + /* + * If one of the process has already identified that we need + * to do prefetch then let it perform the prefetch and allow + * others to proceed with the work in hand. Another option + * could be that we allow all of them to participate in + * prefetching. But, most of this work done under mutex or + * LWLock so ultimately we may end up in prefetching + * sequentially. + */ I mean, IIUC, the call to PrefetchBuffer() is not done under any lock. And that's the slow part. The tiny amount of time we spend updating the prefetch information under the mutex should be insignificant compared to the cost of actually reading the buffer. Unless I'm missing something. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
