Re: Parallel Seq Scan
От | Amit Langote |
---|---|
Тема | Re: Parallel Seq Scan |
Дата | |
Msg-id | 5643E350.1050107@lab.ntt.co.jp обсуждение исходный текст |
Ответ на | Re: Parallel Seq Scan (Robert Haas <robertmhaas@gmail.com>) |
Список | 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 по дате отправления: