Re: Understanding EXPLAIN ANALYZE estimates when loops != 1

From: Philip Semanchuk <philip(at)americanefficient(dot)com>
To: David Rowley <dgrowleyml(at)gmail(dot)com>
Cc: PostgreSQL General <pgsql-general(at)lists(dot)postgresql(dot)org>
Subject: Re: Understanding EXPLAIN ANALYZE estimates when loops != 1
Date: 2020-08-20 15:21:42
Message-ID: 88D7CF3A-B5D2-4585-9CFE-F62097F1EBCA@americanefficient.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

> On Aug 19, 2020, at 6:24 PM, David Rowley <dgrowleyml(at)gmail(dot)com> wrote:
>
> On Thu, 20 Aug 2020 at 09:55, Philip Semanchuk
> <philip(at)americanefficient(dot)com> wrote:
>> I could use some help interpreting EXPLAIN ANALYZE output.
>>
>> -> Index Scan using ix_foo on t1 (cost=0.69..68.57 rows=3283 width=105) (actual time=0.006..0.918 rows=3760 loops=94)
>>
>> The actual rows returned by this plan node ~= 3760 * 94 = 353,440.
>
> Yes. It's total rows / loops rounded to the nearest integer number.
>
>> Did postgres expect (estimate) 3283 rows from this join, or 3283 * 94 = 308,602?
>
> Yes, that's the case at least when the node is not a Parallel node.
> If this index scan was part of a parameterized nested loop, then
> you'll see the estimate of the number of expected loops from the outer
> side of the join.

Thanks, I was wondering where the 94 came from.

> Same question for this node.
>>
>> -> Parallel Index Scan using pk_xyz on xyz (cost=0.29..2354.67 rows=54285 width=25) (actual time=0.049..6.326 rows=14864 loops=5)
>>
>> Actual rows ~= 14864 * 5 = 74,320, estimate = 54285 or 54285 * 5?
>
> So parallel plans are a bit more complex. The row estimates are the
> total estimated rows / the amount of workers we expect to do useful
> work. You might expect the divisor there to be an integer number
> since you can't really have 0.5 workers. However, it's more complex
> than that since the leader has other tasks to take care of such as
> pulling tuples from workers, it's not dedicated to helping out.

Sounds like it help to set max_parallel_workers = 1 before running EXPLAIN ANALYZE in order to simplify the numbers, yes? Or is there a possibility that doing so would send the planner down an entirely different path?

>
> If you're into reading C code, then there's more information in
> https://github.com/postgres/postgres/blob/master/src/backend/optimizer/path/costsize.c#L5699
> , if you hunt around for usages of that function then you'll see the
> estimated row counts are divided by the return value of that function.

Yes, I’ve spent some time reading that file and its relatives. It’s been helpful.

Much appreciated
Philip

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Ron 2020-08-20 15:39:41 Re: EXTERNAL: Re: Loading Oracle Spatial Data to Postgresql
Previous Message Ko, Christina 2020-08-20 14:57:47 RE: EXTERNAL: Re: Loading Oracle Spatial Data to Postgresql