> On 14 Jan 2025, at 13:58, John Naylor wrote:
>
> That's not as clear-cut as I thought. To avoid regressions, I've gone
> back to an earlier idea to pass the direction to the comparator, but
> this time keep it simple by using the same comparator for sort and
> unique, similar to v9.
Looks g
I wrote:
> On Tue, Jan 7, 2025 at 12:59 PM Andrey M. Borodin
> wrote:
> > And one more case.
> > BTW for pre-sorted desc arrays desc sorting is slower:
>
> Right, that's because the sort template special-cases pre-sorted input, and
> that only works for descending input if the comparator is wire
On Tue, Jan 7, 2025 at 12:59 PM Andrey M. Borodin
wrote:
>
> I'm worried about another case that we cannot measure: PREPAREARR(a) on
empty array will return new array.
In theory, yes, but it doesn't happen in our regression tests, so it might
be worth looking into making that happen before worryi
> On 7 Jan 2025, at 09:43, John Naylor wrote:
>
>> With the same setup as in the first message of this thread we can do:
>>
>> postgres=# SELECT _int_contains(arr,ARRAY[1]) FROM arrays_to_sort;
>>
>> before patch patch
>> Time: 567.928 ms
>> after patch
>> Time: 890.297 ms
>> timing of this
On Tue, Jan 7, 2025 at 12:47 AM Nathan Bossart wrote:
>
> On Mon, Jan 06, 2025 at 05:54:29PM +0700, John Naylor wrote:
> > Those functions from common/int.h are probably not good when inlined
> > (see comment there).
>
> +1. In fact, I think this comment was added because of the ST_MED3()
> funct
On Mon, Jan 6, 2025 at 10:51 PM Andrey M. Borodin wrote:
>
> > On 6 Jan 2025, at 15:54, John Naylor wrote:
> > argument. Like some other patches in this series, this does have the
> > side effect of removing the ability to skip quinique(), so that should
> > be benchmarked (I can do that this we
On Mon, Jan 06, 2025 at 05:54:29PM +0700, John Naylor wrote:
> Those functions from common/int.h are probably not good when inlined
> (see comment there).
+1. In fact, I think this comment was added because of the ST_MED3()
function in sort_template.h [0]. IIRC clang handles this just fine, but
> On 6 Jan 2025, at 15:54, John Naylor wrote:
>>
>> I thought about it, but decided to rename the routine.
>> Here's a version 7 with compASC().
>
> I had the right idea, but the wrong function -- HEAD already had a
> suitable comp function, and one that works well with inlined
> specialized
On Sun, Jan 5, 2025 at 1:15 AM Andrey M. Borodin wrote:
>
> > On 4 Jan 2025, at 10:24, John Naylor wrote:
> >
> > v6-0001:
> >
> > +static int
> > +unique_cmp(const void *a, const void *b)
> > +{
> > + int32 aval = *((const int32 *) a);
> > + int32 bval = *((const int32 *) b);
> > +
> > + return
> On 4 Jan 2025, at 10:24, John Naylor wrote:
>
> v6-0001:
>
> +static int
> +unique_cmp(const void *a, const void *b)
> +{
> + int32 aval = *((const int32 *) a);
> + int32 bval = *((const int32 *) b);
> +
> + return pg_cmp_s32(aval, bval);
> +}
>
> I'm not sure it makes sense to create a who
On Sat, Dec 21, 2024 at 12:16 AM Andrey M. Borodin wrote:
>
>
>
> > On 16 Dec 2024, at 14:02, John Naylor wrote:
> >
> > Sorry, I forgot this part earlier. Yes, let's have the private function.
>
> PFA v6.
v6-0001:
+static int
+unique_cmp(const void *a, const void *b)
+{
+ int32 aval = *((const
> On 16 Dec 2024, at 14:02, John Naylor wrote:
>
> Sorry, I forgot this part earlier. Yes, let's have the private function.
PFA v6.
I was poking around intarray and trying not to bash everything. It seems to me
that overall code readability should be seriously reworked. Even if no one is
go
On Mon, Dec 16, 2024 at 12:58 AM Andrey M. Borodin wrote:
> So, let's do the function private for intarray and try to remove as much code
> as possible?
Sorry, I forgot this part earlier. Yes, let's have the private function.
--
John Naylor
Amazon Web Services
On Mon, Dec 16, 2024 at 12:58 AM Andrey M. Borodin wrote:
>
> > On 11 Dec 2024, at 11:39, John Naylor wrote:
> > Also, I was hoping get an answer for how this would actually affect
> > intarray use you've seen in the wild. If the answer is "I don't know
> > of any one who uses this either", then
> On 11 Dec 2024, at 11:39, John Naylor wrote:
>
> On Mon, Dec 9, 2024 at 8:02 PM Andrey M. Borodin wrote:
>>
>> I think commit message states that it's better to opt-in for interruptible
>> sort. So I do not think making sort interruptible is a blocker for making
>> global specialized sor
On Mon, Dec 9, 2024 at 8:02 PM Andrey M. Borodin wrote:
>
> > On 6 Dec 2024, at 08:49, John Naylor wrote:
> > That's a good thing to raise right now -- intarray currently doesn't
> > have one, and we haven't gotten complaints from people trying to sort
> > large arrays and cancel the query. This
> On 6 Dec 2024, at 08:49, John Naylor wrote:
>
> https://www.postgresql.org/message-id/CA%2BhUKGKztHEWm676csTFjYzortziWmOcf8HDss2Zr0muZ2xfEg%40mail.gmail.com
Wow, what a thread!
"Simpsons Already Did It"
> On Fri, Dec 6, 2024 at 1:32 AM Andrey M. Borodin wrote:
>>
>>> On 5 Dec 2024, at 15:
On Fri, Dec 6, 2024 at 1:32 AM Andrey M. Borodin wrote:
>
> > On 5 Dec 2024, at 15:16, John Naylor wrote:
> > I believe src/port/qsort.c was meant to be just for the standard sort
> > interface as found in a C library. We do have one globally visible
> > special sort here:
> > src/backend/utils/
> On 5 Dec 2024, at 15:16, John Naylor wrote:
>
> I tried on an older Intel chip and got similar results, so we'll go
> with your original comparator:
Ack.
> I believe src/port/qsort.c was meant to be just for the standard sort
> interface as found in a C library. We do have one globally visi
On Wed, Dec 4, 2024 at 2:47 PM Andrey M. Borodin wrote:
> sort_int32_cmp Time: 543.690 ms
> sort_int32_cmp_2 Time: 609.019 ms
> sort_int32_cmp_4 Time: 612.219 ms
>
> So, I'd stick with sort_int32_cmp. But, perhaps, on Intel we might have
> different results.
I tried on an older Intel chip and go
> On 2 Dec 2024, at 08:39, John Naylor wrote:
>
> On Mon, Dec 2, 2024 at 1:12 AM Andrey M. Borodin wrote:
>>
>>> On 25 Nov 2024, at 17:50, John Naylor wrote:
>>>
>>> I'd like to see the two sort specializations combined
>>> into one, using a local comparator that knows when to reverse the
>
> On 9 Sep 2024, at 02:31, David Rowley wrote:
>
> Also, unless Andrey is happy for you to tag onto the work he's doing,
> I'd suggest another thread for that work. I don't think there's any
> good reason for that work to delay Andrey's work.
Stepan asked for mentoring project, so I handed hi
On Mon, 9 Sept 2024 at 01:00, Stepan Neretin wrote:
> Hi, why do you think that I rejected Andrey's offer? I included his patch
> first in my own. Yes, patch 2-0006 is the only patch to which I have not
> attached any statistics and it looks really dubious. But the rest seem
> useful. Above, I
Hi, why do you think that I rejected Andrey's offer? I included his patch
first in my own. Yes, patch 2-0006 is the only patch to which I have not
attached any statistics and it looks really dubious. But the rest seem
useful. Above, I attached a speed graph for one of the patches and tps(
pgbench)
On Sun, 8 Sept 2024 at 20:51, Stepan Neretin wrote:
> Hi! I rebase, clean and some refactor my patches.
I'm unsure what exactly is going on with this thread. It started with
Andrey proposing a patch to speed up intarray sorting and now it's
turned into you proposing 10 patches which implement a s
Hi! I rebase, clean and some refactor my patches.
Best regards, Stepan Neretin.
From f88cbb80e478d5ac3f23945b4ba0ee881f0d9cd4 Mon Sep 17 00:00:00 2001
From: "Andrey M. Borodin"
Date: Sun, 8 Sep 2024 15:43:39 +0700
Subject: [PATCH v2 01/10] Use specialized sort facilities
---
contrib/intarray/_i
On Tue, Jul 16, 2024 at 1:47 AM Andrey M. Borodin
wrote:
>
>
> > On 15 Jul 2024, at 12:52, Stepan Neretin wrote:
> >
> >
> > I run benchmark with my patches:
> > ./pgbench -c 10 -j2 -t1000 -d postgres
> >
> > pgbench (18devel)
> > starting vacuum...end.
> > transaction type:
> > scaling factor:
> On 15 Jul 2024, at 12:52, Stepan Neretin wrote:
>
>
> I run benchmark with my patches:
> ./pgbench -c 10 -j2 -t1000 -d postgres
>
> pgbench (18devel)
> starting vacuum...end.
> transaction type:
> scaling factor: 10
> query mode: simple
> number of clients: 10
> number of threads: 2
> max
On Mon, Jul 15, 2024 at 4:52 PM Stepan Neretin wrote:
>
>
> On Mon, Jul 15, 2024 at 12:23 PM Антуан Виолин
> wrote:
>
>> Hello all.
>>>
>>> I have decided to explore more areas in which I can optimize and have
>>> added
>>> two new benchmarks. Do you have any thoughts on this?
>>>
>>> postgres=#
On Mon, Jul 15, 2024 at 12:23 PM Антуан Виолин
wrote:
> Hello all.
>>
>> I have decided to explore more areas in which I can optimize and have
>> added
>> two new benchmarks. Do you have any thoughts on this?
>>
>> postgres=# select bench_int16_sort(100);
>> bench_int16_sort
>>
>>
>>
>
> Hello all.
>
> I have decided to explore more areas in which I can optimize and have added
> two new benchmarks. Do you have any thoughts on this?
>
> postgres=# select bench_int16_sort(100);
> bench_int16_sort
>
>
> --
On Sat, Jun 8, 2024 at 1:50 AM Stepan Neretin wrote:
> Hello all.
>
> I am interested in the proposed patch and would like to propose some
> additional changes that would complement it. My changes would introduce
> similar optimizations when working with a list of integers or object
> identifiers
Hello all.
I am interested in the proposed patch and would like to propose some
additional changes that would complement it. My changes would introduce
similar optimizations when working with a list of integers or object
identifiers. Additionally, my patch includes an extension for benchmarking,
w
Em sáb., 18 de mai. de 2024 às 15:52, Andrey M. Borodin <
x4...@yandex-team.ru> escreveu:
> Hi!
>
> In a thread about sorting comparators[0] Andres noted that we have
> infrastructure to help compiler optimize sorting. PFA attached PoC
> implementation. I've checked that it indeed works on the ben
Hi!
In a thread about sorting comparators[0] Andres noted that we have
infrastructure to help compiler optimize sorting. PFA attached PoC
implementation. I've checked that it indeed works on the benchmark from that
thread.
postgres=# CREATE TABLE arrays_to_sort AS
SELECT array_shuffle(a) ar
35 matches
Mail list logo