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. 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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
