| From: | Dilip Kumar <dilipbalaut(at)gmail(dot)com> |
|---|---|
| To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
| Cc: | Thomas Munro <thomas(dot)munro(at)enterprisedb(dot)com>, Haribabu Kommi <kommi(dot)haribabu(at)gmail(dot)com>, Rafia Sabih <rafia(dot)sabih(at)enterprisedb(dot)com>, tushar <tushar(dot)ahuja(at)enterprisedb(dot)com>, Amit Khandekar <amitdkhan(dot)pg(at)gmail(dot)com>, Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>, Andres Freund <andres(at)anarazel(dot)de>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Parallel bitmap heap scan |
| Date: | 2017-03-07 16:40:21 |
| Message-ID: | CAFiTN-sCf9o3JuQhN9y7oFS2zWoDKQJ3vtxu0KDjPW8RSa9R5g@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Tue, Mar 7, 2017 at 10:07 PM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
> It's not about speed. It's about not forgetting to prefetch. Suppose
> that worker 1 becomes the prefetch worker but then doesn't return to
> the Bitmap Heap Scan node for a long time because it's busy in some
> other part of the plan tree. Now you just stop prefetching; that's
> bad. You want prefetching to continue regardless of which workers are
> busy doing what; as long as SOME worker is executing the parallel
> bitmap heap scan, prefetching should continue as needed.
Right, I missed this part. I will fix this.
--
Regards,
Dilip Kumar
EnterpriseDB: http://www.enterprisedb.com
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Robert Haas | 2017-03-07 16:42:21 | Re: Parallel seq. plan is not coming against inheritance or partition table |
| Previous Message | Peter Eisentraut | 2017-03-07 16:39:22 | Re: Logical replication existing data copy |