Re: Parallel Seq Scan - Mailing list pgsql-hackers

From Jim Nasby
Subject Re: Parallel Seq Scan
Date
Msg-id 54B07224.6080203@BlueTreble.com
Whole thread Raw
In response to Re: Parallel Seq Scan  (Stephen Frost <sfrost@snowman.net>)
List pgsql-hackers
On 1/9/15, 11:24 AM, Stephen Frost wrote:
> What I was advocating for up-thread was to consider multiple "parallel"
> paths and to pick whichever ends up being the lowest overall cost.  The
> flip-side to that is increased planning time.  Perhaps we can come up
> with an efficient way of working out where the break-point is based on
> the non-parallel cost and go at it from that direction instead of
> building out whole paths for each increment of parallelism.

I think at some point we'll need the ability to stop planning part-way through for queries producing really small
estimates.If the first estimate you get is 1000 units, does it really make sense to do something like try every
possiblejoin permutation, or attempt to parallelize?
 
-- 
Jim Nasby, Data Architect, Blue Treble Consulting
Data in Trouble? Get it in Treble! http://BlueTreble.com



pgsql-hackers by date:

Previous
From: Dean Rasheed
Date:
Subject: Re: Possible typo in create_policy.sgml
Next
From: Bruce Momjian
Date:
Subject: Re: libpq 9.4 requires /etc/passwd?