On Sat, Aug 10, 2019 at 1:20 AM Heikki Linnakangas wrote:
> Hmm. Wouldn't it be more straightforward to have the extra tupindex
> field at the end of the struct?
> The initial sorting phase would deal with SortTuples, and the merge
> phase would deal with MergeTuples. The same comparison routines
On 10/08/2019 02:14, Peter Geoghegan wrote:
The easy part was removing SortTuple.tupindex itself -- it was fairly
natural to stash that in the slab allocation for each tape. I used the
aset.c trick of having a metadata "chunk" immediately prior to address
that represents the allocation proper --
On Fri, Sep 9, 2016 at 6:14 AM Heikki Linnakangas wrote:
> 1. SortTuple.tupindex is not used when the sort fits in memory. If we
> also got rid of the isnull1 flag, we could shrink SortTuple from 24
> bytes to 16 bytes (on 64-bit systems). That would allow you to pack more
> tuples into memory, wh
