Re: Choosing parallel_degree

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.

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?

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.

ATB,

P