From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
---|---|
To: | Dilip Kumar <dilipbalaut(at)gmail(dot)com> |
Cc: | 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-02-19 17:04:00 |
Message-ID: | CA+Tgmoa3bwb20ignwqQRnxAkgLL_JdACsfCM=OuQ2xj2CJJByg@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Sun, Feb 19, 2017 at 9:59 PM, Dilip Kumar <dilipbalaut(at)gmail(dot)com> wrote:
> I can imagine it can get executed over and over if plan is something like below.
>
> NestLoopJoin
> -> SeqScan
> -> Gather
> -> Parallel Bitmap Heap Scan
>
> But in such case every time the Inner node of the NLJ will be
> rescanned i.e. Gather will be rescanned which in turn shutdown
> workers.
Yeah, but it looks like ExecReScanGather gets rid of the workers, but
reuses the existing DSM. I'm not quite sure what happens to the DSA.
It looks like it probably just hangs around from the previous
iteration, which means that any allocations will also hang around.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2017-02-19 17:13:51 | Re: Replication vs. float timestamps is a disaster |
Previous Message | David Christensen | 2017-02-19 17:02:38 | Re: [PATCH] Add pg_disable_checksums() and supporting infrastructure |