On Wed, Jan 11, 2017 at 4:05 PM, Robert Haas wrote:
>> While investigating why Rushabh Lathia's Gather Merge patch sometimes
>> fails to pick a Gather Merge plan even when it really ought to do so,
>> I ran smack into this problem. I discovered that this is more than a
>> cosmetic issue. The cos
On Wed, Jan 11, 2017 at 1:24 PM, Robert Haas wrote:
>> Well, it's not *that* consistent. If we were estimating all the numbers
>> underneath the Gather as being per-worker numbers, that would make some
>> amount of sense. But neither the other seqscan, nor the hash on it, nor
>> the hashjoin's o
On Wed, Nov 2, 2016 at 10:54 PM, Tom Lane wrote:
I got confused by that a minute ago, so no you're not alone. The problem
is even worse in join cases. For example:
Gather (cost=34332.00..53265.35 rows=100 width=8)
Workers Planned: 2
-> Hash Join (cost=2.00.
On Wed, Nov 2, 2016 at 10:44 PM, Tomas Vondra
wrote:
> Although - it is estimating 1M rows, but only "per worker" estimates are
> shown, and because there are 2 workers planned it says 1M/2.4 which is the
> 416k. I agree it's a bit unclear, but at least it's consistent with how we
> treat loops (i
On Wed, Nov 2, 2016 at 4:00 PM, Tom Lane wrote:
> Tomas Vondra writes:
>> while eye-balling some explain plans for parallel queries, I got a bit
>> confused by the row count estimates. I wonder whether I'm alone.
>
> I got confused by that a minute ago, so no you're not alone. The problem
> is e
On Wed, Nov 2, 2016 at 2:42 PM, Tomas Vondra
wrote:
> BTW is it really a good idea to use nloops to track the number of workers
> executing a given node? How will that work if once we get parallel nested
> loops and index scans?
We already have parallel nested loops with inner index scans.
--
R
Tomas Vondra writes:
> On 11/02/2016 11:56 PM, Tomas Vondra wrote:
>> On 11/02/2016 09:00 PM, Tom Lane wrote:
>>> Tomas Vondra writes:
while eye-balling some explain plans for parallel queries, I got a bit
confused by the row count estimates. I wonder whether I'm alone.
>>> I got confu
On 11/02/2016 11:56 PM, Tomas Vondra wrote:
On 11/02/2016 09:00 PM, Tom Lane wrote:
Tomas Vondra writes:
while eye-balling some explain plans for parallel queries, I got a bit
confused by the row count estimates. I wonder whether I'm alone.
I got confused by that a minute ago, so no you're n
On 11/02/2016 09:00 PM, Tom Lane wrote:
Tomas Vondra writes:
while eye-balling some explain plans for parallel queries, I got a bit
confused by the row count estimates. I wonder whether I'm alone.
I got confused by that a minute ago, so no you're not alone. The problem
is even worse in join
Tomas Vondra writes:
> while eye-balling some explain plans for parallel queries, I got a bit
> confused by the row count estimates. I wonder whether I'm alone.
I got confused by that a minute ago, so no you're not alone. The problem
is even worse in join cases. For example:
Gather (cost=34
Hi,
while eye-balling some explain plans for parallel queries, I got a bit
confused by the row count estimates. I wonder whether I'm alone.
Consider for example a simple seq scan query, which in non-parallel
explain looks like this:
QUERY PLAN
-
11 matches
Mail list logo
