Re: Disk-based hash aggregate's cost model - Mailing list pgsql-hackers

From Jeff Davis
Subject Re: Disk-based hash aggregate's cost model
Date
Msg-id d518e363381470aa4b8595281a8384017ddf80da.camel@j-davis.com
Whole thread Raw
In response to Re: Disk-based hash aggregate's cost model  (Tomas Vondra <tomas.vondra@2ndquadrant.com>)
List pgsql-hackers
On Fri, 2020-09-04 at 21:01 +0200, Tomas Vondra wrote:
> Wouldn't it be enough to just use a slot with smaller tuple
> descriptor?
> All we'd need to do is creating the descriptor in ExecInitAgg after
> calling find_hash_columns, and using it for rslot/wslot, and then
> "mapping" the attributes in hashagg_spill_tuple (which already almost
> does that, to the extra cost should be 0) and when reading the
> spilled
> tuples.

That's a good point, it's probably not much code to make it work.

> So I'm not quite buying the argument that this would make
> measurable difference ...

I meant "projection of all input tuples" (i.e. CP_SMALL_TLIST) has a
cost. If we project only at spill time, it should be fine.

Regards,
    Jeff Davis





pgsql-hackers by date:

Previous
From: Andres Freund
Date:
Subject: Re: Improving connection scalability: GetSnapshotData()
Next
From: Alvaro Herrera
Date:
Subject: Re: A micro-optimisation for walkdir()