| From: | Atri Sharma <atri(dot)jiit(at)gmail(dot)com> |
|---|---|
| To: | Jeff Davis <pgsql(at)j-davis(dot)com> |
| Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Tomas Vondra <tv(at)fuzzy(dot)cz>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: 9.5: Memory-bounded HashAgg |
| Date: | 2014-08-14 16:02:10 |
| Message-ID: | CAOeZVifhtGQyFKM2dmH3wiTQQ5MZ+pj9RZN7UqmNvF39+ccgMA@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Thursday, August 14, 2014, Jeff Davis <pgsql(at)j-davis(dot)com> wrote:
> On Thu, 2014-08-14 at 10:06 -0400, Tom Lane wrote:
> > If you're following the HashJoin model, then what you do is the same
> thing
> > it does: you write the input tuple back out to the pending batch file for
> > the hash partition that now contains key 1001, whence it will be
> processed
> > when you get to that partition. I don't see that there's any special
> case
> > here.
>
> HashJoin only deals with tuples. With HashAgg, you have to deal with a
> mix of tuples and partially-computed aggregate state values. Not
> impossible, but it is a little more awkward than HashJoin.
>
>
+1
Not to mention future cases if we start maintaining multiple state
values,in regarded to grouping sets.
Regards,
Atri
--
Regards,
Atri
*l'apprenant*
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Baker, Keith [OCDUS Non-J&J] | 2014-08-14 16:08:34 | Re: Proposal to add a QNX 6.5 port to PostgreSQL |
| Previous Message | Jeff Davis | 2014-08-14 15:39:24 | Re: 9.5: Memory-bounded HashAgg |