Re: Top-N sorts verses parallelism

2017-12-19 Thread Robert Haas
On Tue, Dec 19, 2017 at 6:54 AM, Thomas Munro wrote: > On Mon, Dec 18, 2017 at 9:29 AM, Robert Haas wrote: >> I went through the callers to create_sort_path and the only one that >> looks like it can pass a limit is the one you and Jeff already >> identified. So I think the question is just whet

Re: Top-N sorts verses parallelism

2017-12-19 Thread Amit Kapila
On Tue, Dec 19, 2017 at 5:24 PM, Thomas Munro wrote: > On Mon, Dec 18, 2017 at 9:29 AM, Robert Haas wrote: >> I went through the callers to create_sort_path and the only one that >> looks like it can pass a limit is the one you and Jeff already >> identified. So I think the question is just whet

Re: Top-N sorts verses parallelism

2017-12-19 Thread Thomas Munro
On Mon, Dec 18, 2017 at 9:29 AM, Robert Haas wrote: > I went through the callers to create_sort_path and the only one that > looks like it can pass a limit is the one you and Jeff already > identified. So I think the question is just whether > create_gather_merge_path needs a similar fix. I migh

Re: Top-N sorts verses parallelism

2017-12-17 Thread Robert Haas
On Fri, Dec 15, 2017 at 4:13 PM, Thomas Munro wrote: > Looks right to me. Commit 3452dc52 just forgot to tell the planner. > I'm pleased about that because it makes this a slam-dunk bug-fix and > not some confusing hard to justify costing problem. Jeff Janes inquired off-list about other places

Re: Top-N sorts verses parallelism

2017-12-15 Thread Thomas Munro
On Sat, Dec 16, 2017 at 9:13 AM, Robert Haas wrote: > On Fri, Dec 15, 2017 at 2:10 PM, Jeff Janes wrote: >> I had hit on the same change. And was also surprised that it was located >> where it was. With the change, it uses the parallel plan all the way down >> to LIMIT 1. >> >> With the patch,

Re: Top-N sorts verses parallelism

2017-12-15 Thread Robert Haas
On Fri, Dec 15, 2017 at 2:10 PM, Jeff Janes wrote: > I had hit on the same change. And was also surprised that it was located > where it was. With the change, it uses the parallel plan all the way down > to LIMIT 1. > > With the patch, it still satisfies make check, so if it introduces errors >

Re: Top-N sorts verses parallelism

2017-12-15 Thread Jeff Janes
On Thu, Dec 14, 2017 at 5:12 PM, Thomas Munro wrote: > > > > This looks like a costing bug. The estimated cost of sorting 416,667 > > estimated tuples in one parallel worker is almost identical to the > estimated > > cost of sorting 1,000,000 tuples when parallelism is turned off. Adding > > so

Re: Top-N sorts verses parallelism

2017-12-14 Thread Thomas Munro
On Fri, Dec 15, 2017 at 10:05 AM, Jeff Janes wrote: > On Tue, Dec 12, 2017 at 10:46 PM, Thomas Munro > wrote: >> >> Hi hackers, >> >> The start-up cost of bounded (top-N) sorts is sensitive at the small >> end of N, and the >> comparison_cost * tuples * LOG2(2.0 * output_tuples) curve doesn't >>

Re: Top-N sorts verses parallelism

2017-12-14 Thread Jeff Janes
On Tue, Dec 12, 2017 at 10:46 PM, Thomas Munro < thomas.mu...@enterprisedb.com> wrote: > Hi hackers, > > The start-up cost of bounded (top-N) sorts is sensitive at the small > end of N, and the > comparison_cost * tuples * LOG2(2.0 * output_tuples) curve doesn't > seem to correspond to reality. H

Re: Top-N sorts verses parallelism

2017-12-13 Thread Jeff Janes
On Tue, Dec 12, 2017 at 10:46 PM, Thomas Munro < thomas.mu...@enterprisedb.com> wrote: > Hi hackers, > > The start-up cost of bounded (top-N) sorts is sensitive at the small > end of N, and the > comparison_cost * tuples * LOG2(2.0 * output_tuples) curve doesn't > seem to correspond to reality.

Re: Top-N sorts verses parallelism

2017-12-13 Thread Robert Haas
On Wed, Dec 13, 2017 at 1:46 AM, Thomas Munro wrote: > Hi hackers, > > The start-up cost of bounded (top-N) sorts is sensitive at the small > end of N, and the > comparison_cost * tuples * LOG2(2.0 * output_tuples) curve doesn't > seem to correspond to reality. Here's a contrived example that com