From: | Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> |
---|---|
To: | Ashutosh Sharma <ashu(dot)coek88(at)gmail(dot)com> |
Cc: | Robert Haas <robertmhaas(at)gmail(dot)com>, Jesper Pedersen <jesper(dot)pedersen(at)redhat(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Page Scan Mode in Hash Index |
Date: | 2017-04-04 10:29:05 |
Message-ID: | CAA4eK1KddmY1+5vzwU3qrxDppzLR51oAH2=WoQHhXmL+UUfveA@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Mon, Mar 27, 2017 at 7:04 PM, Ashutosh Sharma <ashu(dot)coek88(at)gmail(dot)com> wrote:
>
> My guess (which could be wrong) is that so->hashso_bucket_buf =
>> InvalidBuffer should be moved back up higher in the function where it
>> was before, just after the first if statement, and that the new
>> condition so->hashso_bucket_buf == so->currPos.buf on the last
>> _hash_dropbuf() should be removed. If that's not right, then I think
>> I need somebody to explain why not.
>
> Okay, as i mentioned above, in case of page scan mode we only keep pin
> on a bucket buf. There won't be any case where we will be having pin
> on overflow buf at the end of scan.
>
What if mark the buffer as invalid after releasing the pin? We are
already doing it that way in btree code, refer
_bt_drop_lock_and_maybe_pin(). I think if we do that way, then we can
do what Robert is suggesting.
--
With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com
From | Date | Subject | |
---|---|---|---|
Next Message | Kyotaro HORIGUCHI | 2017-04-04 10:29:09 | Re: FDW and parallel execution |
Previous Message | Amit Kapila | 2017-04-04 10:26:26 | Re: Page Scan Mode in Hash Index |