Re: [HACKERS] More ideas for speeding up sorting

2016-09-09 Thread Tom Lane
Peter Geoghegan writes: > I know that in practice, even virtual address space is significantly > less than 64-bits on x86_64, so I think that there should be several > bits there for the taking, even if the addresses are not aligned > (although, they are). However, I have no idea

Re: [HACKERS] More ideas for speeding up sorting

2016-09-09 Thread Peter Geoghegan
On Fri, Sep 9, 2016 at 1:54 PM, Peter Geoghegan wrote: >> 2. We could easily categorize incoming tuples as the come in, into those >> that have a leading NULL, and others. If we kept them in separate arrays, or >> perhaps grow memtuples from bottom-up for non-NULLs and from

Re: [HACKERS] More ideas for speeding up sorting

2016-09-09 Thread Peter Geoghegan
On Fri, Sep 9, 2016 at 6:14 AM, Heikki Linnakangas wrote: > A few things caught my eye while hacking on the latest round of sorting > patches. This is how it begins. :-) > Starting a new thread because these are orthogonal to the things > discussed on the other threads: > > 1.

[HACKERS] More ideas for speeding up sorting

2016-09-09 Thread Heikki Linnakangas
A few things caught my eye while hacking on the latest round of sorting patches. Starting a new thread because these are orthogonal to the things discussed on the other threads: 1. SortTuple.tupindex is not used when the sort fits in memory. If we also got rid of the isnull1 flag, we could