From: | Andres Freund <andres(at)anarazel(dot)de> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Andrew Gierth <andrew(at)tao11(dot)riddles(dot)org(dot)uk>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Excessive disk usage in WindowAgg |
Date: | 2019-11-04 18:06:08 |
Message-ID: | 20191104180608.lhk6ryftibx5zpvm@alap3.anarazel.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hi,
On 2019-11-04 12:18:48 -0500, Tom Lane wrote:
> Andrew Gierth <andrew(at)tao11(dot)riddles(dot)org(dot)uk> writes:
> > Using 92MB of disk for one integer seems excessive; the reason is clear
> > from the explain:
> > ...
> > so the whole width of the table is being stored in the tuplestore used
> > by the windowagg.
>
> > In create_windowagg_plan, we have:
>
> > /*
> > * WindowAgg can project, so no need to be terribly picky about child
> > * tlist, but we do need grouping columns to be available
> > */
> > subplan = create_plan_recurse(root, best_path->subpath, CP_LABEL_TLIST);
>
> > Obviously we _do_ need to be more picky about this; it seems clear that
> > using CP_SMALL_TLIST | CP_LABEL_TLIST would be a win in many cases.
> > Opinions?
>
> Seems reasonable to me, do you want to do the honors?
I was briefly wondering if this ought to be backpatched. -0 here, but...
Greetings,
Andres Freund
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2019-11-04 18:07:33 | Re: Missed check for too-many-children in bgworker spawning |
Previous Message | Andres Freund | 2019-11-04 18:04:09 | Re: 64 bit transaction id |