Re: Parallel Seq Scan - Mailing list pgsql-hackers

From Amit Langote
Subject Re: Parallel Seq Scan
Date
Msg-id 5643E350.1050107@lab.ntt.co.jp
Whole thread Raw
In response to Re: Parallel Seq Scan  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers
On 2015/11/12 4:26, Robert Haas wrote:
> On Wed, Nov 11, 2015 at 12:59 PM, Pavel Stehule <pavel.stehule@gmail.com> wrote:
>> I have a first query
>>
>> I looked on EXPLAIN ANALYZE output and the numbers of filtered rows are
>> differen
> 
> Hmm, I see I was right about people finding more bugs once this was
> committed.  That didn't take long.

I encountered one more odd behavior:

postgres=# EXPLAIN ANALYZE SELECT abalance FROM pgbench_accounts WHERE aid
= 23466;                                                           QUERY PLAN


-----------------------------------------------------------------------------------------------------------------------------------Gather
(cost=1000.00..65207.88 rows=1 width=4) (actual
 
time=17450.595..17451.151 rows=1 loops=1)  Number of Workers: 4  ->  Parallel Seq Scan on pgbench_accounts
(cost=0.00..64207.78rows=1
 
width=4) (actual time=55.934..157001.134 rows=2 loops=1)        Filter: (aid = 23466)        Rows Removed by Filter:
18047484Planningtime: 0.198 msExecution time: 17453.565 ms
 
(7 rows)


The #rows removed here is almost twice the number of rows in the table
(10m). Also, the #rows selected shown is 2 for Parallel Seq Scan whereas
only 1 row is selected.

Thanks,
Amit




pgsql-hackers by date:

Previous
From: Greg Stark
Date:
Subject: Re: can we add SKIP LOCKED to UPDATE?
Next
From: Gavin Flower
Date:
Subject: Re: can we add SKIP LOCKED to UPDATE?