> That's worth trying out. It might also then be worth trying to push both
> unordered values -- the big one up / the small one down. I've seen other
> implementations do that, but don't remember where, or what it's called.
It is important that we do not do 2 compares two avoid one copy (assignm
On Tue, May 23, 2023 at 4:10 PM Benjamin Coutu wrote:
>
> Greetings,
>
> I would like to revisit the discussion and concur with John's perspective
that incremental progress through small, successive modifications is the
appropriate approach to move forward. Therefore, I would like to propose
two d
Greetings,
I would like to revisit the discussion and concur with John's perspective that
incremental progress through small, successive modifications is the appropriate
approach to move forward. Therefore, I would like to propose two distinct ideas
aimed at enhancing the functionality of inser
> "Looks like"?
I cannot find the reference, but I've read a while back that a well-known
company from Redwood uses it for their in-memory columnar storage. That might
have just been a rumor or might have been research only - not sure. It does not
really matter anyways.
> SortTuples are curren
On Tue, Sep 27, 2022 at 4:39 PM Benjamin Coutu wrote:
>
> Getting back to improvements for small sort runs, it might make sense to
consider using in-register based sorting via sorting networks for very
small runs.
> It looks like some of the commercial DBMSs do this very successfully.
"Looks lik
Getting back to improvements for small sort runs, it might make sense to
consider using in-register based sorting via sorting networks for very small
runs.
This talk is specific to database sorting and illustrates how such an approach
can be vectorized:
https://youtu.be/HeFwVNHsDzc?list=PLSE8O
On Fri, Aug 26, 2022 at 9:06 PM Benjamin Coutu wrote:
>
> Another idea could be to run a binary insertion sort and use a much higher
> threshold. This could significantly cut down on comparisons (especially with
> presorted runs, which are quite common in real workloads).
Comparisons that must
> convenient if you know the type at compile time. See the attached,
> which I had laying around when I was looking at PDQuicksort. I believe
> it's similar to what you have in mind.
That looks very promising.
I also love your recent proposal of partitioning into null and non-null. I
suspect that
On Thu, Aug 25, 2022 at 5:55 PM Benjamin Coutu wrote:
>
> Hello,
>
> Inspired by the recent discussions[1][2] around sort improvements, I took a
> look around the code and noticed the use of a somewhat naive version of
> insertion sort within the broader quicksort code.
>
> The current implement
Hello,
Inspired by the recent discussions[1][2] around sort improvements, I took a
look around the code and noticed the use of a somewhat naive version of
insertion sort within the broader quicksort code.
The current implementation (see sort_template.h) is practically the textbook
version of i
10 matches
Mail list logo
