From: | Peter Geoghegan <pg(at)bowt(dot)ie> |
---|---|
To: | Jeff Davis <pgsql(at)j-davis(dot)com> |
Cc: | Heikki Linnakangas <hlinnaka(at)iki(dot)fi>, Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)com>, Taylor Vesely <tvesely(at)pivotal(dot)io>, Adam Lee <ali(at)pivotal(dot)io>, Melanie Plageman <mplageman(at)pivotal(dot)io>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Memory-Bounded Hash Aggregation |
Date: | 2020-02-05 18:40:30 |
Message-ID: | CAH2-WzmSXoBuFyPnuDg8C6h95bJNXgMhy11JP0hFhW1h20UK7w@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Wed, Feb 5, 2020 at 10:37 AM Jeff Davis <pgsql(at)j-davis(dot)com> wrote:
> > LogicalTapeSetExtend() seems to work in a way that assumes that the
> > tape is frozen. It would be good to document that assumption, and
> > possible enforce it by way of an assertion. The same remark applies
> > to
> > any other assumptions you're making there.
>
> Can you explain? I am not freezing any tapes in Hash Aggregation, so
> what about LogicalTapeSetExtend() assumes the tape is frozen?
Sorry, I was very unclear. I meant to write just the opposite: you
assume that the tapes are *not* frozen. If you're adding a new
capability to logtape.c, it makes sense to be clear on the
requirements on tapeset state or individual tape state.
--
Peter Geoghegan
From | Date | Subject | |
---|---|---|---|
Next Message | Mark Dilger | 2020-02-05 18:55:32 | Re: [HACKERS] advanced partition matching algorithm for partition-wise join |
Previous Message | Jeff Davis | 2020-02-05 18:37:15 | Re: Memory-Bounded Hash Aggregation |