On Sun, 4 Aug 2024 at 02:11, David Rowley wrote:
> I did some more testing on this on a few different machines; apple M2
> Ultra, AMD 7945HX and with a Raspberry Pi 4.
I did some more testing on this patch today as I wanted to see what
Intel CPUs thought about it. The only modern Intel CPU I ha
On Sun, 28 Jul 2024 at 00:51, David Rowley wrote:
> I did another round of testing on the SIMD patch (attached as v5-0001)
> as I wondered if the SIMD loop maybe shouldn't wait too long before
> copying the bytes to the destination string. I had wondered if the
> JSON string was very large that i
On Wed, 24 Jul 2024 at 22:55, Heikki Linnakangas wrote:
>
> On 02/07/2024 07:49, David Rowley wrote:
> > I've attached a rebased set of patches. The previous set no longer applied.
>
> I looked briefly at the first patch. Seems reasonable.
>
> One little thing that caught my eye is that in popula
On 02/07/2024 07:49, David Rowley wrote:
I've attached a rebased set of patches. The previous set no longer applied.
I looked briefly at the first patch. Seems reasonable.
One little thing that caught my eye is that in populate_scalar(), you
sometimes make a temporary copy of the string to a
I've attached a rebased set of patches. The previous set no longer applied.
David
v3-0001-Add-len-parameter-to-escape_json.patch
Description: Binary data
v3-0002-Use-SIMD-processing-for-escape_json.patch
Description: Binary data
v3-0003-Special-case-text-type-conversion-in-datum_to_jso.patc
Thanks for having a look.
On Wed, 12 Jun 2024 at 00:08, Melih Mutlu wrote:
> In 0001 patch, I see that there are some escape_json() calls with
> NUL-terminated strings and gets the length by calling strlen(), like below:
>
>> - escape_json(&buf, "timestamp");
>> + escape_json(&buf, "timestamp",
On 2024-06-11 Tu 08:08, Melih Mutlu wrote:
Hi David,
Thanks for the patch.
In 0001 patch, I see that there are some escape_json() calls with
NUL-terminated strings and gets the length by calling strlen(), like
below:
- escape_json(&buf, "timestamp");
+ escape_json(&buf, "timestamp"
Hi David,
Thanks for the patch.
In 0001 patch, I see that there are some escape_json() calls with
NUL-terminated strings and gets the length by calling strlen(), like below:
- escape_json(&buf, "timestamp");
> + escape_json(&buf, "timestamp", strlen("timestamp"));
Wouldn't using escape_json_c
On Fri, 24 May 2024 at 08:34, Andrew Dunstan wrote:
> That's all pretty nice! I'd take the win on this rather than wait for
> some hypothetical patch that changes how output functions work.
On re-think of that, even if we changed the output functions to write
directly to a StringInfo, we wouldn't
On 2024-05-22 We 22:15, David Rowley wrote:
On Thu, 23 May 2024 at 13:23, David Rowley wrote:
Master:
$ pgbench -n -f bench.sql -T 10 -M prepared postgres | grep tps
tps = 362.494309 (without initial connection time)
tps = 363.182458 (without initial connection time)
tps = 362.679654 (without
On Thu, 23 May 2024 at 13:23, David Rowley wrote:
> Master:
> $ pgbench -n -f bench.sql -T 10 -M prepared postgres | grep tps
> tps = 362.494309 (without initial connection time)
> tps = 363.182458 (without initial connection time)
> tps = 362.679654 (without initial connection time)
>
> Master +
Currently the escape_json() function takes a cstring and char-by-char
checks each character in the string up to the NUL and adds the escape
sequence if the character requires it.
Because this function requires a NUL terminated string, we're having
to do a little more work in some places. For exam
12 matches
Mail list logo
