On Thu, Apr 20, 2017 at 11:35 PM, Jeff Janes wrote:
> Regardless, it seems like something is
> getting overlooked.
I agree with this.
> The way final_cost_hashjoin charges for the actual data
> comparison is via pg_proc.procost, rather than just assuming 1.0. I don't
> know if we would want to
On Thu, Apr 20, 2017 at 3:46 AM, Ashutosh Bapat <
ashutosh.ba...@enterprisedb.com> wrote:
> On Thu, Apr 20, 2017 at 7:47 AM, Jeff Janes wrote:
> >
> > In cost_size.c, there is this comment block:
> >
> > +* Note: in this cost model, AGG_SORTED and AGG_HASHED have
> exactly
> > the
> > +
On Thu, Apr 20, 2017 at 4:16 PM, Ashutosh Bapat
wrote:
> but cost this without numGroups.
>
> /*
> * The transCost.per_tuple component of aggcosts should be charged once
> * per input tuple, corresponding to the costs of evaluating the aggregate
> * transfns and their input expr
On Thu, Apr 20, 2017 at 7:47 AM, Jeff Janes wrote:
>
> In cost_size.c, there is this comment block:
>
> +* Note: in this cost model, AGG_SORTED and AGG_HASHED have exactly
> the
> +* same total CPU cost, but AGG_SORTED has lower startup cost. If
> the
> +* input path is al
In cost_size.c, there is this comment block:
+* Note: in this cost model, AGG_SORTED and AGG_HASHED have exactly
the
+* same total CPU cost, but AGG_SORTED has lower startup cost. If
the
+* input path is already sorted appropriately, AGG_SORTED should be
+* preferr
