On Tue, Oct 27, 2015 at 5:26 AM, Ashutosh Bapat <ashutosh.bapat@enterprisedb.com> wrote: > > > > On Fri, Oct 23, 2015 at 2:43 AM, Robert Haas <robertmhaas@gmail.com> wrote: >> >> On Wed, Oct 21, 2015 at 5:23 AM, Ashutosh Bapat >> <ashutosh.bapat@enterprisedb.com> wrote: >> > Increasing the sorting cost factor (when use_remote_estimates = false) from >> > 1.1 to 1.2 makes the difference disappear. >> > >> > Since the startup costs for postgres_fdw are large portion of total cost, >> > extra 10% of rest of the cost is comparable to 1% fuzzy limit. IMO, we >> > shouldn't bother too much about it as the path costs are not much different. >> >> My feeling is that cranking the sorting cost factor up to 20-25% would >> be a good idea, just so we have less unnecessary plan churn. I dunno >> if sorting always costs that much, but if a 10% cost overhead is >> really 1% because it only applies to a fraction of the cost, I don't >> think that's good. The whole point was to pick something large enough >> that we wouldn't take the sorted path unless we will benefit from the >> sort, and clearly that's not what happened here. >> > > PFA patch with the default multiplication factor for sort bumped up to 1.2. >
+/* If no remote estimates, assume a sort costs 10% extra */ +#define DEFAULT_FDW_SORT_MULTIPLIER 1.2
The above comment should not be 20%?
Ah! Here's patch with comment fixed.
--
Best Wishes, Ashutosh Bapat EnterpriseDB Corporation The Postgres Database Company
