| From: | Jeff Davis <pgsql(at)j-davis(dot)com> |
|---|---|
| To: | Andres Freund <andres(at)anarazel(dot)de>, David Rowley <david(dot)rowley(at)2ndquadrant(dot)com> |
| Cc: | Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)com>, Heikki Linnakangas <hlinnaka(at)iki(dot)fi>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Spilling hashed SetOps and aggregates to disk |
| Date: | 2018-06-05 17:33:20 |
| Message-ID: | 1528220000.2742.45.camel@j-davis.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Tue, 2018-06-05 at 05:57 -0700, Andres Freund wrote:
> But I think my proposal to continue use a hashtable for the already
> known groups, and sorting for additional groups would largely address
> that largely, right? We couldn't deal with groups becoming too
> large,
> but easily with the number of groups becoming too large.
The eviction problem is the same whether we partition or sort: which
groups do we keep in memory, and which ones do we send to disk?
You are essentially suggesting that we do what my patch already does
w.r.t eviction: don't evict; the groups that appear first stay in
memory for the duration, later groups may be forced to disk.
Regards,
Jeff Davis
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Jonathan S. Katz | 2018-06-05 17:34:17 | Re: commitfest 2018-07 |
| Previous Message | Andres Freund | 2018-06-05 17:29:52 | Variable-length FunctionCallInfoData |