Re: Choosing parallel_degree

On 8 April 2016 at 17:00, Paul Ramsey <pramsey(at)cleverelephant(dot)ca> wrote:

> On Fri, Apr 8, 2016 at 8:23 AM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
> > On Fri, Apr 8, 2016 at 1:22 AM, Amit Kapila <amit(dot)kapila16(at)gmail(dot)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