I wrote:
> I agree this is only useful in development. Removal sounds fine to me,
> so I'll do that soon.
This is done.
--
John Naylor
EDB: http://www.enterprisedb.com
On Fri, May 20, 2022 at 5:43 AM Tom Lane wrote:
>
> Peter Geoghegan writes:
> > On Thu, May 19, 2022 at 1:12 PM Justin Pryzby wrote:
> >> Should these debug lines be removed ?
> >>
> >> elog(DEBUG1, "qsort_tuple");
>
> > I agree -- DEBUG1 seems too chatty for something like this. DEBUG2
> >
Peter Geoghegan writes:
> On Thu, May 19, 2022 at 1:12 PM Justin Pryzby wrote:
>> Should these debug lines be removed ?
>>
>> elog(DEBUG1, "qsort_tuple");
> I agree -- DEBUG1 seems too chatty for something like this. DEBUG2
> would be more appropriate IMV. Though I don't feel very strongly
On Thu, May 19, 2022 at 1:12 PM Justin Pryzby wrote:
> Should these debug lines be removed ?
>
> elog(DEBUG1, "qsort_tuple");
I agree -- DEBUG1 seems too chatty for something like this. DEBUG2
would be more appropriate IMV. Though I don't feel very strongly about
it.
--
Peter Geoghegan
On Fri, Apr 22, 2022 at 11:37:29AM +0700, John Naylor wrote:
> On Fri, Apr 22, 2022 at 11:13 AM David Rowley wrote:
> >
> > On Thu, 21 Apr 2022 at 19:09, John Naylor
> > wrote:
> > > I intend to commit David's v2 fix next week, unless there are
> > > objections, or unless he beats me to it.
> >
On Fri, Apr 22, 2022 at 4:37 PM John Naylor
wrote:
> On Fri, Apr 22, 2022 at 11:13 AM David Rowley wrote:
> > On Thu, 21 Apr 2022 at 19:09, John Naylor
> > wrote:
> > > I intend to commit David's v2 fix next week, unless there are
> > > objections, or unless he beats me to it.
> >
> > I wasn't
On Fri, Apr 22, 2022 at 11:13 AM David Rowley wrote:
>
> On Thu, 21 Apr 2022 at 19:09, John Naylor
> wrote:
> > I intend to commit David's v2 fix next week, unless there are
> > objections, or unless he beats me to it.
>
> I wasn't sure if you wanted to handle it or not, but I don't mind
>
On Thu, 21 Apr 2022 at 19:09, John Naylor wrote:
> I intend to commit David's v2 fix next week, unless there are
> objections, or unless he beats me to it.
I wasn't sure if you wanted to handle it or not, but I don't mind
doing it, so I just pushed it after a small adjustment to a comment.
I intend to commit David's v2 fix next week, unless there are
objections, or unless he beats me to it.
--
John Naylor
EDB: http://www.enterprisedb.com
> Okay, this makes logical sense and is a smaller patch to boot. I've
> re-run my tests (attached) to make sure we have our bases covered. I'm
> sharing the min-of-five, as before, but locally I tried . The
My sentence there was supposed to read "I tried using median and it
was a bit less noisy".
On Tue, Apr 19, 2022 at 12:30 PM David Rowley wrote:
>
> Thanks for looking at this.
>
> On Tue, 19 Apr 2022 at 02:11, John Naylor
> wrote:
> > IIUC, this function is called by tuplesort_begin_common, which in turn
> > is called by tuplesort_begin_{heap, indexes, etc}. The latter callers
> >
Thanks for looking at this.
On Tue, 19 Apr 2022 at 02:11, John Naylor wrote:
> IIUC, this function is called by tuplesort_begin_common, which in turn
> is called by tuplesort_begin_{heap, indexes, etc}. The latter callers
> set the onlyKey and now oneKeySort variables as appropriate, and
>
On Tue, Apr 12, 2022 at 7:58 AM David Rowley wrote:
>
> I've attached the patch I tested. It was thrown together very quickly
> just to try out the performance. If it's interesting I can polish it
> up a bit. If not, I didn't waste too much time.
@@ -959,6 +965,10 @@
On Thu, Apr 14, 2022 at 1:46 PM David Rowley wrote:
>
> On Wed, 13 Apr 2022 at 23:19, John Naylor
> wrote:
> > More broadly than the regression, Thomas' is very often the fastest of
> > all, at the cost of more binary size. David's is occasionally slower
> > than v15 or v15 with revert, but
On Wed, 13 Apr 2022 at 23:19, John Naylor wrote:
> More broadly than the regression, Thomas' is very often the fastest of
> all, at the cost of more binary size. David's is occasionally slower
> than v15 or v15 with revert, but much of that is a slight difference
> and some is probably noise.
As promised, I've done another round of tests (script and spreadsheet
attached) with
- v15 with 6974924347 and cc58eecc5d reverted
- v15 with Thomas' patch
- v15 with David's patch
- v15 as is ("std")
...where v15 is at 7b735f8b52ad. This time I limited it to int,
bigint, and text types.
Since
On Mon, 11 Apr 2022 at 22:11, John Naylor wrote:
>
> On Mon, Apr 11, 2022 at 5:34 AM David Rowley wrote:
>
> > With this particular test, v15 is about 15% *slower* than v14. I
> > didn't know what to blame at first, so I tried commenting out the sort
> > specialisations and got the results in
On Mon, Apr 11, 2022 at 5:34 AM David Rowley wrote:
> With this particular test, v15 is about 15% *slower* than v14. I
> didn't know what to blame at first, so I tried commenting out the sort
> specialisations and got the results in the red bars in the graph. This
> made it about 7.5% *faster*
On Mon, 11 Apr 2022 at 09:44, Thomas Munro wrote:
> David Rowley privately reported a performance regression when sorting
> single ints with a lot of duplicates, in a case that previously hit
> qsort_ssup() but now hits qsort_tuple_int32() and then has to call the
> tiebreaker comparator. Note
On Sun, Apr 10, 2022 at 2:44 PM Thomas Munro wrote:
> David Rowley privately reported a performance regression when sorting
> single ints with a lot of duplicates, in a case that previously hit
> qsort_ssup() but now hits qsort_tuple_int32() and then has to call the
> tiebreaker comparator.
Hi,
David Rowley privately reported a performance regression when sorting
single ints with a lot of duplicates, in a case that previously hit
qsort_ssup() but now hits qsort_tuple_int32() and then has to call the
tiebreaker comparator. Note that this comes up only for sorts in a
query, not for
Here is the updated insertion sort threshold patch based on Thomas'
experimental v4 0010, with adjusted regression test output. I only
found a couple places where it could make sense to add sort keys to
test queries, but 1) not enough to make a big difference and 2) the
adjustments looked out of
On Mon, Apr 4, 2022 at 4:32 AM Andres Freund wrote:
> Would be good to get this committed soon, so we can see further ubsan
> violations introduced in the next few days (and so I can unblock my local dev
> tests :P).
Pushed (with a minor tweak).
Hi,
On 2022-04-03 17:46:28 +1200, Thomas Munro wrote:
> On Sun, Apr 3, 2022 at 11:11 AM Andres Freund wrote:
> > On 2022-04-03 09:45:13 +1200, Thomas Munro wrote:
> > > I think we just need to decide up front if we're in a situation that
> > > can't provide datum1/isnull1 (in this case because
On Sun, Apr 3, 2022 at 11:11 AM Andres Freund wrote:
> On 2022-04-03 09:45:13 +1200, Thomas Munro wrote:
> > I think we just need to decide up front if we're in a situation that
> > can't provide datum1/isnull1 (in this case because it's an expression
> > index), and skip the optimised paths.
Hi,
On 2022-04-03 09:45:13 +1200, Thomas Munro wrote:
> On Sun, Apr 3, 2022 at 9:03 AM Andres Freund wrote:
> > It's certainly not pretty that copytup_cluster() can use SortTuples without
> > actually using SortTuples. Afaics it basically only computes isnull1/datum1
> > if
> >
On Sun, Apr 3, 2022 at 9:03 AM Andres Freund wrote:
> It's certainly not pretty that copytup_cluster() can use SortTuples without
> actually using SortTuples. Afaics it basically only computes isnull1/datum1 if
> state->indexInfo->ii_IndexAttrNumbers[0] == 0.
I think we just need to decide up
Hi,
On 2022-04-02 15:20:27 -0500, Justin Pryzby wrote:
> On Sat, Apr 02, 2022 at 06:41:30PM +0700, John Naylor wrote:
> > On Sat, Apr 2, 2022 at 5:27 PM Thomas Munro wrote:
> > > Reproduced locally, using the same few lines from the cluster.sql
> > > test. I'll try to dig more tomorrow...
> >
On Sun, Apr 3, 2022 at 8:20 AM Justin Pryzby wrote:
> @@ -4126,22 +4126,23 @@ copytup_cluster(Tuplesortstate *state, SortTuple
> *stup, void *tup)
> + stup->isnull1 = false;
Looks like I might have failed to grok the scheme for encoding null
into SortTuple objects. It's clearly
Hi,
On 2022-04-03 08:07:58 +1200, Thomas Munro wrote:
> On Sun, Apr 3, 2022 at 12:41 AM John Naylor
> wrote:
> > On Sat, Apr 2, 2022 at 5:27 PM Thomas Munro wrote:
> > > Reproduced locally, using the same few lines from the cluster.sql
> > > test. I'll try to dig more tomorrow...
> >
> >
On Sat, Apr 02, 2022 at 06:41:30PM +0700, John Naylor wrote:
> On Sat, Apr 2, 2022 at 5:27 PM Thomas Munro wrote:
> > Reproduced locally, using the same few lines from the cluster.sql
> > test. I'll try to dig more tomorrow...
>
> Thanks! Unfortunately I can't reproduce locally with clang
On Sun, Apr 3, 2022 at 12:41 AM John Naylor
wrote:
> On Sat, Apr 2, 2022 at 5:27 PM Thomas Munro wrote:
> > Reproduced locally, using the same few lines from the cluster.sql
> > test. I'll try to dig more tomorrow...
>
> Thanks! Unfortunately I can't reproduce locally with clang 13/gcc 11,
>
On Sat, Apr 2, 2022 at 5:27 PM Thomas Munro wrote:
> Reproduced locally, using the same few lines from the cluster.sql
> test. I'll try to dig more tomorrow...
Thanks! Unfortunately I can't reproduce locally with clang 13/gcc 11,
with -Og or -O2 with CFLAGS="-fsanitize=undefined,alignment" ...
On Sat, Apr 2, 2022 at 5:27 PM Thomas Munro wrote:
> It looks like UBsan sees a problem, per BF animal kestrel:
>
> /mnt/resource/bf/build/kestrel/HEAD/pgsql.build/../pgsql/src/backend/utils/sort/tuplesort.c:722:51:
> runtime error: load of value 96, which is not a valid value for type
> 'bool'
On Sat, Apr 2, 2022 at 9:38 PM John Naylor wrote:
> On Fri, Apr 1, 2022 at 4:43 AM Thomas Munro wrote:
> > On Thu, Mar 31, 2022 at 11:09 PM John Naylor
> > wrote:
> > > In a couple days I'm going to commit the v3 patch "accelerate tuple
> > > sorting for common types" as-is after giving it one
I wrote:
> I started towards incorporating the change in insertion sort threshold
> (part of 0010), but that caused regression test failures, so that will
> have to wait for a bit of analysis and retesting. (My earlier tests
> were done in a separate module.)
The failures seem to be where sort
On Fri, Apr 1, 2022 at 4:43 AM Thomas Munro wrote:
>
> On Thu, Mar 31, 2022 at 11:09 PM John Naylor
> wrote:
> > In a couple days I'm going to commit the v3 patch "accelerate tuple
> > sorting for common types" as-is after giving it one more look, barring
> > objections.
Pushed.
> Hi John,
>
>
On Thu, Mar 31, 2022 at 11:09 PM John Naylor
wrote:
> In a couple days I'm going to commit the v3 patch "accelerate tuple
> sorting for common types" as-is after giving it one more look, barring
> objections.
Hi John,
Thanks so much for all the work you've done here! I feel bad that I
lobbed
In a couple days I'm going to commit the v3 patch "accelerate tuple
sorting for common types" as-is after giving it one more look, barring
objections.
I started towards incorporating the change in insertion sort threshold
(part of 0010), but that caused regression test failures, so that will
have
I wrote:
> > 0010 - Thresholds on my TODO list.
>
> I did some basic tests on the insertion sort thresholds, and it looks
> like we could safely and profitably increase the current value from 7
> to 20 or so, in line with other more recent implementations. I've
> attached an addendum on top of
I wrote:
> 0010 - Thresholds on my TODO list.
I did some basic tests on the insertion sort thresholds, and it looks
like we could safely and profitably increase the current value from 7
to 20 or so, in line with other more recent implementations. I've
attached an addendum on top of 0012 and the
Hi,
I've run a few tests to get some feel for the effects of various
comparators on Datums containing int32. I've attached the full
results, as well as the (messy) patch which applies on top of 0012 to
run the tests. I'll excerpt some of those results as I go through them
here. For now, I only
On Tue, Jan 18, 2022 at 9:58 PM Peter Geoghegan wrote:
>
> On Tue, Jan 18, 2022 at 6:39 PM John Naylor
> wrote:
> > Editorializing the null position in queries is not very common in my
> > experience. Not null is interesting since it'd be trivial to pass
> > constant false to the same
On Tue, Jan 18, 2022 at 6:39 PM John Naylor
wrote:
> Editorializing the null position in queries is not very common in my
> experience. Not null is interesting since it'd be trivial to pass
> constant false to the same Apply[XYZ]SortComparator() and let the
> compiler remove all those branches
I wrote:
> That said, I think what I'll do next is test the v3-0001 standalone
> patch with tuplesort specializations for more data types. I already
> have a decent test script that I can build on for this.
I've run a test with 10 million records using all types found in the
v3 patch "accelerate
On Mon, Jun 28, 2021 at 8:16 PM Thomas Munro wrote:
[v4 patchset]
Hi Thomas,
(Sorry for the delay -- I have some time to put into this now.)
> The lower numbered patches are all things that are reused in many
> places, and in my humble opinion improve the notation and type safety
> and code
On Sun, Aug 1, 2021 at 5:41 PM Thomas Munro wrote:
> On Fri, Jul 30, 2021 at 12:34 PM John Naylor
> wrote:
> > I got around to getting a benchmark together to serve as a starting point.
> > I based it off something I got from the archives, but don't remember where
> > (I seem to remember Tomas
On Mon, Aug 2, 2021 at 12:40 PM Thomas Munro wrote:
> Great! I saw similar sorts of numbers. It's really just a few
> crumbs, nothing compared to the gains David just found over in the
> thread "Use generation context to speed up tuplesorts", but on the
> bright side, these crumbs will be
On Fri, Jul 30, 2021 at 12:34 PM John Naylor
wrote:
> I got around to getting a benchmark together to serve as a starting point. I
> based it off something I got from the archives, but don't remember where (I
> seem to remember Tomas Vondra wrote the original, but not sure). To start I
> just
On Fri, Jul 30, 2021 at 7:11 PM Peter Geoghegan wrote:
> If you're going to specialize the sort routine for unsigned integer
> style abbreviated keys then you might as well cover all relevant
> opclasses/types. Almost all abbreviated key schemes produce
> conditioned datums that are designed to
On Fri, Jul 30, 2021 at 7:47 AM Ranier Vilela wrote:
> The patch attached does not apply cleanly,
> please can fix it?
It applies just fine with "patch", for those wondering.
--
John Naylor
EDB: http://www.enterprisedb.com
Em qui., 29 de jul. de 2021 às 21:34, John Naylor <
john.nay...@enterprisedb.com> escreveu:
>
> On Sun, Jul 4, 2021 at 12:27 AM Thomas Munro
> wrote:
> >
> > Since you are experimenting with tuplesort and likely thinking similar
> > thoughts, here's a patch I've been using to explore that area.
On Fri, Jul 30, 2021 at 3:34 AM John Naylor
wrote:
> I'm also attaching your tuplesort patch so others can see what exactly I'm
> comparing.
If you're going to specialize the sort routine for unsigned integer
style abbreviated keys then you might as well cover all relevant
opclasses/types.
On Sun, Jul 4, 2021 at 12:27 AM Thomas Munro wrote:
>
> Since you are experimenting with tuplesort and likely thinking similar
> thoughts, here's a patch I've been using to explore that area. I've
> seen it get, for example, ~1.18x speedup for simple index builds in
> favourable winds (YMMV,
On Thu, Jun 17, 2021 at 1:20 PM Thomas Munro wrote:
> On Thu, Jun 17, 2021 at 1:14 PM Tom Lane wrote:
> > The big problem in my mind, which would not be alleviated in the
> > slightest by having a separate file, is that it'd be easy to miss
> > removing entries if they ever become obsolete.
>
>
On Thu, Jul 15, 2021 at 7:50 AM vignesh C wrote:
> The patch does not apply on Head anymore, could you rebase and post a
> patch. I'm changing the status to "Waiting for Author".
The patch set is fine. The error is my fault since I attached an
experimental addendum and neglected to name it as
On Sun, Jul 4, 2021 at 9:58 AM Thomas Munro wrote:
>
> On Fri, Jul 2, 2021 at 2:32 PM John Naylor
> wrote:
> > I suspect if we experiment on two extremes of type "heaviness" (accessing
> > and comparing trivial or not), such as uint32 and tuplesort, we'll have a
> > pretty good idea what the
On Fri, Jul 2, 2021 at 2:32 PM John Naylor wrote:
> I suspect if we experiment on two extremes of type "heaviness" (accessing and
> comparing trivial or not), such as uint32 and tuplesort, we'll have a pretty
> good idea what the parameters should be, if anything different. I'll do some
>
On Thu, Jul 1, 2021 at 6:10 PM Thomas Munro wrote:
> One thing I'm wondering about is whether it's worth having stuff to
> support future experimentation like ST_SORT_SMALL_THRESHOLD and
> ST_COMPARE_RET_TYPE in the tree, or whether we should pare it back to
> the minimal changes that definitely
On Fri, Jul 2, 2021 at 4:39 AM John Naylor wrote:
> For item pointers, it made sense to try doing math to reduce the number of
> branches. That made things worse, so let's try the opposite: Increase the
> number of branches so we do less math. In the attached patch (applies on top
> of your
I wrote:
> One of the points of the talk I linked to is "if doing the sensible thing
makes things worse, try something silly instead".
For item pointers, it made sense to try doing math to reduce the number of
branches. That made things worse, so let's try the opposite: Increase the
number of
On Tue, Jun 29, 2021 at 2:56 AM Thomas Munro wrote:
> Here's a version that includes a rather hackish test module that you
> might find useful to explore various weird effects. Testing sorting
> routines is really hard, of course... there's a zillion parameters and
> things you could do in the
On Tue, Jun 29, 2021 at 1:11 PM Thomas Munro wrote:
> I spotted a mistake in v3: I didn't rename ST_COMPARE_TYPE to
> ST_COMPARE_RET_TYPE in the 0009 patch (well, I did, but forgot to
> commit before I ran git format-patch). I won't send another tarball
> just for that, but will correct it next
I spotted a mistake in v3: I didn't rename ST_COMPARE_TYPE to
ST_COMPARE_RET_TYPE in the 0009 patch (well, I did, but forgot to
commit before I ran git format-patch). I won't send another tarball
just for that, but will correct it next time.
Hi John,
On Tue, Jun 29, 2021 at 7:13 AM John Naylor
wrote:
> I plan to do some performance testing with VACUUM, ANALYZE etc soon, to see
> if I can detect any significant differences.
Thanks!
> I did a quick check of the MacOS/clang binary size (no debug symbols):
>
> master:8108408
>
On Wed, Jun 16, 2021 at 1:55 AM Thomas Munro wrote:
[v2 patch]
Hi Thomas,
I plan to do some performance testing with VACUUM, ANALYZE etc soon, to see
if I can detect any significant differences.
I did a quick check of the MacOS/clang binary size (no debug symbols):
master:8108408
On Thu, Jun 17, 2021 at 1:14 PM Tom Lane wrote:
> The big problem in my mind, which would not be alleviated in the
> slightest by having a separate file, is that it'd be easy to miss
> removing entries if they ever become obsolete.
I suppose you could invent some kind of declaration syntax in a
Thomas Munro writes:
> Perhaps one day we could add a
> secondary file, not updated by that mechanism, that holds a manually
> maintained list for cases like this.
Yeah, the comments in pgindent already speculate about that. For
now, those include and exclude lists are short enough that keeping
On Thu, Jun 17, 2021 at 11:40 AM Tom Lane wrote:
> Thomas Munro writes:
> > Hmm, well it was only recently damaged by commit def5b065, and that's
> > because I'd forgotten to put ST_ELEMENT_TYPE into typedefs.list, and I
> > was correcting that in this patch.
>
> If ST_ELEMENT_TYPE isn't
Thomas Munro writes:
> Hmm, well it was only recently damaged by commit def5b065, and that's
> because I'd forgotten to put ST_ELEMENT_TYPE into typedefs.list, and I
> was correcting that in this patch.
If ST_ELEMENT_TYPE isn't recognized as a typedef by the buildfarm's
typedef collectors, this
On Wed, Jun 16, 2021 at 2:54 PM Thomas Munro wrote:
> Hi Zhihong,
>
> On Thu, Jun 17, 2021 at 8:13 AM Zhihong Yu wrote:
> > In 0001-Add-bsearch-and-unique-templates-to-sort_template.h.patch :
> >
> > - const ST_ELEMENT_TYPE *
> ST_SORT_PROTO_ARG);
> > +
Hi Zhihong,
On Thu, Jun 17, 2021 at 8:13 AM Zhihong Yu wrote:
> In 0001-Add-bsearch-and-unique-templates-to-sort_template.h.patch :
>
> - const ST_ELEMENT_TYPE *
> ST_SORT_PROTO_ARG);
> + const ST_ELEMENT_TYPE
>
On Tue, Jun 15, 2021 at 10:55 PM Thomas Munro
wrote:
> On Mon, Mar 15, 2021 at 1:09 PM Thomas Munro
> wrote:
> > On Sun, Mar 14, 2021 at 5:03 PM Zhihong Yu wrote:
> > > + * Remove duplicates from an array. Return the new size.
> > > + */
> > > +ST_SCOPE size_t
> > > +ST_UNIQUE(ST_ELEMENT_TYPE
On Mon, Mar 15, 2021 at 1:09 PM Thomas Munro wrote:
> On Sun, Mar 14, 2021 at 5:03 PM Zhihong Yu wrote:
> > + * Remove duplicates from an array. Return the new size.
> > + */
> > +ST_SCOPE size_t
> > +ST_UNIQUE(ST_ELEMENT_TYPE *array,
> >
> > The array is supposed to be sorted, right ?
> > The
On Sun, Mar 14, 2021 at 5:03 PM Zhihong Yu wrote:
> For 0001-Add-bsearch-and-unique-templates-to-sort_template.h.patch :
>
> + * Remove duplicates from an array. Return the new size.
> + */
> +ST_SCOPE size_t
> +ST_UNIQUE(ST_ELEMENT_TYPE *array,
>
> The array is supposed to be sorted, right ?
>
Hi,
For 0001-Add-bsearch-and-unique-templates-to-sort_template.h.patch :
+ * Remove duplicates from an array. Return the new size.
+ */
+ST_SCOPE size_t
+ST_UNIQUE(ST_ELEMENT_TYPE *array,
The array is supposed to be sorted, right ?
The comment should mention this.
Cheers
On Sat, Mar 13, 2021
On Sat, Mar 13, 2021 at 3:49 PM Thomas Munro wrote:
> On Fri, Mar 12, 2021 at 7:58 AM Andres Freund wrote:
> > I wish we had the same for bsearch... :)
>
> Glibc already has the definition of the traditional void-based
> function in /usr/include/bits/stdlib-bsearch.h, so the generated code
>
On Fri, Mar 12, 2021 at 7:58 AM Andres Freund wrote:
> I wish we had the same for bsearch... :)
Glibc already has the definition of the traditional void-based
function in /usr/include/bits/stdlib-bsearch.h, so the generated code
when the compiler can see the comparator definition is already good
Hi,
I wish we had the same for bsearch... :)
On 2021-03-03 17:17:13 +1300, Thomas Munro wrote:
> As for which cases are actually worth specialising, I've attached the
> example that Andres mentioned earlier; it seems like a reasonable
> candidate to go ahead and commit too, but I realised that
On Wed, Mar 3, 2021 at 10:25 AM Daniel Gustafsson wrote:
> > On 18 Feb 2021, at 04:09, Thomas Munro wrote:
> > In another thread[1], I proposed $SUBJECT, but then we found a better
> > solution to that thread's specific problem. The general idea is still
> > good though: it's possible to (1)
> On 18 Feb 2021, at 04:09, Thomas Munro wrote:
> In another thread[1], I proposed $SUBJECT, but then we found a better
> solution to that thread's specific problem. The general idea is still
> good though: it's possible to (1) replace several existing copies of
> our qsort algorithm with one,
Hi,
On 2021-02-18 16:09:49 +1300, Thomas Munro wrote:
> In another thread[1], I proposed $SUBJECT, but then we found a better
> solution to that thread's specific problem. The general idea is still
> good though: it's possible to (1) replace several existing copies of
> our qsort algorithm with
Hello,
In another thread[1], I proposed $SUBJECT, but then we found a better
solution to that thread's specific problem. The general idea is still
good though: it's possible to (1) replace several existing copies of
our qsort algorithm with one, and (2) make new specialised versions a
bit more
83 matches
Mail list logo
