On 8 April 2016 at 17:00, Paul Ramsey <pram...@cleverelephant.ca> wrote:
> On Fri, Apr 8, 2016 at 8:23 AM, Robert Haas <robertmh...@gmail.com> wrote: > > On Fri, Apr 8, 2016 at 1:22 AM, Amit Kapila <amit.kapil...@gmail.com> > wrote: > >> Other than that, patch looks good and I have marked it as Ready For > >> Committer. Hope, we get this for 9.6. > > > > Committed. I think this is likely to make parallel query > > significantly more usable in 9.6. > > I'm kind of worried that it will make it yet less usable for PostGIS, > since approaches that ignore costs in favour of relpages will > dramatically under-resource our queries. I can spin a query for > multiple seconds on a table with less than 100K records, not even > trying very hard. > Doesn't sound good. > Functions have very unequal CPU costs, and we're talking here about > using CPUs more effectively, why are costs being given the see-no-evil > treatment? This is as true in core as it is in PostGIS, even if our > case is a couple orders of magnitude more extreme: a filter based on a > complex combination of regex queries will use an order of magnitude > more CPU than one that does a little math, why plan and execute them > like they are the same? > Functions have user assignable costs. > As it stands now, it seems like out of the box PostGIS users will > actually not see much benefit from parallelism unless they manhandle > their configuration settings to force it. > Does this concern apply to this patch, or to the general situation for 9.6. Please suggest what you would like to see. -- Simon Riggs http://www.2ndQuadrant.com/ <http://www.2ndquadrant.com/> PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
