| From: | Dilip Kumar <dilipbalaut(at)gmail(dot)com> |
|---|---|
| To: | Andres Freund <andres(at)anarazel(dot)de> |
| Cc: | pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Parallel bitmap heap scan |
| Date: | 2016-10-19 04:17:35 |
| Message-ID: | CAFiTN-u8PJWrmiOe4p6Eic2dOMy_qrKMsX5HUDxNHa5O2zCCpw@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Tue, Oct 18, 2016 at 1:45 AM, Andres Freund <andres(at)anarazel(dot)de> wrote:
> I don't quite understand why the bitmap has to be parallel at all. As
> far as I understand your approach as described here, the only thing that
> needs to be shared are the iteration arrays. Since they never need to
> be resized and such, it seems to make a lot more sense to just add an
> API to share those, instead of the whole underlying hash.
You are right that we only share iteration arrays. But only point is
that each entry of iteration array is just a pointer to hash entry.
So either we need to build hash in shared memory (my current approach)
or we need to copy each hash element at shared location (I think this
is going to be expensive).
Let me know if I am missing something..
--
Regards,
Dilip Kumar
EnterpriseDB: http://www.enterprisedb.com
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Amit Langote | 2016-10-19 05:27:21 | Re: postgres_fdw : altering foreign table not invalidating prepare statement execution plan. |
| Previous Message | Dilip Kumar | 2016-10-19 04:13:10 | Re: Parallel bitmap heap scan |