On Fri, Jul 3, 2015 at 10:05 PM, Amit Kapila <amit.kapil...@gmail.com> wrote:
> Attached, find the rebased version of patch.
>
> Note - You need to first apply the assess-parallel-safety patch which you
> can find at:
> http://www.postgresql.org/message-id/CAA4eK1JjsfE_dOsHTr_z1P_cBKi_X4C4X3d7Nv=vwx9fs7q...@mail.gmail.com
I ran some performance tests on a 16 core machine with large shared
buffers, so there is no IO involved.
With the default value of cpu_tuple_comm_cost, parallel plan is not
getting generated even if we are selecting 100K records from 40
million records. So I changed the value to '0' and collected the
performance readings.
Here are the performance numbers:
selectivity(millions) Seq scan(ms) Parallel scan
2 workers
4 workers 8 workers
0.1 11498.93 4821.40
3305.84 3291.90
0.4 10942.98 4967.46
3338.58 3374.00
0.8 11619.44 5189.61
3543.86 3534.40
1.5 12585.51 5718.07
4162.71 2994.90
2.7 14725.66 8346.96
10429.05 8049.11
5.4 18719.00 20212.33 21815.19
19026.99
7.2 21955.79 28570.74 28217.60
27042.27
The average table row size is around 500 bytes and query selection
column width is around 36 bytes.
when the query selectivity goes more than 10% of total table records,
the parallel scan performance is dropping.
Regards,
Hari Babu
Fujitsu Australia
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
