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:

Reply via email to