Re: [HACKERS] AGG_HASHED cost estimate

2017-04-20 Thread Ashutosh Bapat
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 >

Re: [HACKERS] AGG_HASHED cost estimate

2017-04-20 Thread Jeff Janes
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 >

Re: [HACKERS] AGG_HASHED cost estimate

2017-04-20 Thread Dilip Kumar
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 >

Re: [HACKERS] AGG_HASHED cost estimate

2017-04-20 Thread Ashutosh Bapat
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 > +

[HACKERS] AGG_HASHED cost estimate

2017-04-19 Thread Jeff Janes
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 +*