On Tue, Jul 7, 2015 at 6:19 AM, Haribabu Kommi <kommi.harib...@gmail.com> wrote: > > 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. >
For reasonable default values for these parameters, still more testing is required. I think instead of 0, tests with 0.001 or 0.0025 for default of cpu_tuple_comm_cost and 100 or 1000 for default of parallel_setup_cost would have been more interesting. > Here are the performance numbers: > > > 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. > These are quite similar to what I have seen in my initial tests, now I think if you add some complex condition in the filter, you will see gains for even 25% or more selectivity (I have added factorial 10 calculation in filter to mimic the complex filter condition). With Regards, Amit Kapila. EnterpriseDB: http://www.enterprisedb.com
