On Mon, Jun 20, 2016 at 2:54 AM, Masahiko Sawada
wrote:
> >> QUERY PLAN
> >>
> >>
>
On Mon, Jun 20, 2016 at 3:06 AM, Satoshi Nagayasu wrote:
> IMHO, "actual rows" of "Parallel Seq Scan" should not be divided by the loops,
> because the total rows processed here is 1000, not 333 * 3.
> I think the actual row value shown here "333 " is a bit confusing
On Mon, Jun 20, 2016 at 12:47 PM, Amit Langote <
langote_amit...@lab.ntt.co.jp> wrote:
>
> On 2016/06/20 15:42, Amit Kapila wrote:
> >
> >>
> >> After spent time to investigate this behaviour, ISTM that the problem
> >> is nloops of Parallel Seq Scan.
> >> Parallel Seq Scan is done only once, but
On Mon, Jun 20, 2016 at 12:24 PM, Masahiko Sawada
wrote:
>
>
> In following case, it look to me that no one collect the tuple.
> But it's obviously incorrect, this query collects a tuple(aid = 10)
actually.
>
> postgres(1)=# explain analyze verbose select * from
On 2016/06/20 15:42, Amit Kapila wrote:
> On Mon, Jun 20, 2016 at 11:48 AM, Masahiko Sawada
> wrote:
>>
>> Hi all,
>>
>> My colleague noticed that the output of EXPLAIN ANALYZE doesn't work
>> fine for parallel seq scan.
>>
[ ... ]
>> For example, the above result shows,
Hi,
2016-06-20 15:42 GMT+09:00 Amit Kapila :
> On Mon, Jun 20, 2016 at 11:48 AM, Masahiko Sawada
> wrote:
>>
>> Hi all,
>>
>> My colleague noticed that the output of EXPLAIN ANALYZE doesn't work
>> fine for parallel seq scan.
>>
>> postgres(1)=#
On Mon, Jun 20, 2016 at 3:42 PM, Amit Kapila wrote:
> On Mon, Jun 20, 2016 at 11:48 AM, Masahiko Sawada
> wrote:
>>
>> Hi all,
>>
>> My colleague noticed that the output of EXPLAIN ANALYZE doesn't work
>> fine for parallel seq scan.
>>
>>
On Mon, Jun 20, 2016 at 11:48 AM, Masahiko Sawada
wrote:
>
> Hi all,
>
> My colleague noticed that the output of EXPLAIN ANALYZE doesn't work
> fine for parallel seq scan.
>
> postgres(1)=# explain analyze verbose select count(*) from
pgbench_accounts ;
>