John Naylor writes:
> On Mon, Jul 18, 2022 at 2:47 PM Martin Kalcher <
> martin.kalc...@aboutsource.net> wrote:
>> One more question. How do i pick a Oid for the functions?
> For this, we recommend running src/include/catalog/unused_oids, and it will
> give you a random range to pick from. That r
On Mon, Jul 18, 2022 at 2:47 PM Martin Kalcher <
martin.kalc...@aboutsource.net> wrote:
> One more question. How do i pick a Oid for the functions?
For this, we recommend running src/include/catalog/unused_oids, and it will
give you a random range to pick from. That reduces the chance of different
Am 18.07.22 um 01:20 schrieb Tom Lane:
(Having said that, even if we were going to implement it with that
definition, I should think that it'd be easiest to do so on the
array-of-Datums representation produced by deconstruct_array.
That way you don't need to do different things for different elem
Am 18.07.22 um 01:20 schrieb Tom Lane:
I would expect that shuffle() only shuffles the first dimension and
keeps the inner arrays intact.
This argument is based on a false premise, ie that Postgres thinks
multidimensional arrays are arrays-of-arrays. They aren't, and
we're not going to start m
Martin Kalcher writes:
> Am 18.07.22 um 00:46 schrieb Tom Lane:
>> This does not look particularly idiomatic, or even type-safe. What you
>> should have done was use deconstruct_array to get an array of Datums and
>> isnull flags, then shuffled those, then used construct_array to build the
>> out
Am 18.07.22 um 00:37 schrieb Thomas Munro:
Seems OK for a worst case. It must still be a lot faster than doing
it in SQL. Now I wonder what the exact requirements would be to
dispatch to a faster version that would handle int4. I haven't
studied this in detail but perhaps to dispatch to a fast
Am 18.07.22 um 00:46 schrieb Tom Lane:
This does not look particularly idiomatic, or even type-safe. What you
should have done was use deconstruct_array to get an array of Datums and
isnull flags, then shuffled those, then used construct_array to build the
output.
(Or, perhaps, use construct_m
Thomas Munro writes:
> Seems OK for a worst case. It must still be a lot faster than doing
> it in SQL. Now I wonder what the exact requirements would be to
> dispatch to a faster version that would handle int4.
I find it impossible to believe that it's worth micro-optimizing
shuffle() to that
Martin Kalcher writes:
> Am 17.07.22 um 08:00 schrieb Thomas Munro:
>>> Actually ... is there a reason to bother with an intarray version
>>> at all, rather than going straight for an in-core anyarray function?
> I played around with the idea of an anyarray shuffle(). The hard part
> was to deal
On Mon, Jul 18, 2022 at 4:15 AM Martin Kalcher
wrote:
> Am 17.07.22 um 08:00 schrieb Thomas Munro:
> >> Actually ... is there a reason to bother with an intarray version
> >> at all, rather than going straight for an in-core anyarray function?
> >> It's not obvious to me that an int4-only version
Am 17.07.22 um 08:00 schrieb Thomas Munro:
Actually ... is there a reason to bother with an intarray version
at all, rather than going straight for an in-core anyarray function?
It's not obvious to me that an int4-only version would have
major performance advantages.
Yeah, that seems like a goo
Am 17.07.22 um 05:32 schrieb David G. Johnston:
+SELECT sample('{1,2,3,4,5,6,7,8,9,10,11,12}', 6) !=
sample('{1,2,3,4,5,6,7,8,9,10,11,12}', 6);
+ ?column?
+--
+ t
+(1 row)
+
While small, there is a non-zero chance for both samples to be equal. This
test should probably just go, I don
Am 17.07.22 um 08:00 schrieb Thomas Munro:
I went to see what Professor Lemire would have to say about all this,
expecting to find a SIMD rabbit hole to fall down for some Sunday
evening reading, but the main thing that jumped out was this article
about the modulo operation required by textbook
Am 17.07.22 um 05:37 schrieb Tom Lane:
Actually ... is there a reason to bother with an intarray version
at all, rather than going straight for an in-core anyarray function?
It's not obvious to me that an int4-only version would have
major performance advantages.
regards
On Sun, Jul 17, 2022 at 3:37 PM Tom Lane wrote:
> I wrote:
> > On the whole, I'd vote for calling it shuffle(), and expecting that
> > we'd also use that name for any future generic version.
>
> Actually ... is there a reason to bother with an intarray version
> at all, rather than going straight
I wrote:
> On the whole, I'd vote for calling it shuffle(), and expecting that
> we'd also use that name for any future generic version.
Actually ... is there a reason to bother with an intarray version
at all, rather than going straight for an in-core anyarray function?
It's not obvious to me tha
On Sat, Jul 16, 2022 at 8:18 PM Tom Lane wrote:
> Martin Kalcher writes:
>
> > - I added a second function sample(), because it is a lot faster to take
> >some elements from an array than to shuffle the whole array and
> >slice it. This function can be removed if it is not wanted.
>
> I
On Sat, Jul 16, 2022 at 7:25 PM Martin Kalcher <
martin.kalc...@aboutsource.net> wrote:
>
> - I added a second function sample(), because it is a lot faster to take
>some elements from an array than to shuffle the whole array and
>slice it. This function can be removed if it is not wanted.
Martin Kalcher writes:
> Am 16.07.22 um 23:56 schrieb Thomas Munro:
>> I understand that this is a specialised int[] shuffle, but I wonder if
>> someone would ever want to have a general array shuffle, and how that
>> would work, in terms of naming convention etc.
> - I am not shure about the nam
Am 16.07.22 um 23:56 schrieb Thomas Munro:
On Fri, Jul 15, 2022 at 8:36 PM Martin Kalcher
wrote:
I would like to see a function like this inside the intarray extension.
Is there any way to get to this point? How is the process to deal with
such proposals?
Hi Martin,
I'm redirecting this to t
On Fri, Jul 15, 2022 at 8:36 PM Martin Kalcher
wrote:
> I would like to see a function like this inside the intarray extension.
> Is there any way to get to this point? How is the process to deal with
> such proposals?
Hi Martin,
I'm redirecting this to the pgsql-hackers@ mailing list, where we
21 matches
Mail list logo
