I wrote:
> We can also shave a
> few percent by having pg_utf8_verifystr use SSE2 for the ascii path. I
> can look into this.
Here's a patch for that. If the input is mostly ascii, I'd expect that
part of the flame graph to shrink by 40-50% and give a small boost
overall.
--
John Naylor
EDB:
Hi,
On 2022-06-24 14:33:00 +0700, John Naylor wrote:
> On Thu, Jun 23, 2022 at 9:06 PM Andres Freund wrote:
> > It looks like there's quite a bit of low hanging fruits to optimize...
>
> Yeah, if escapes and control characters are rare, adding an SSE2 fast
> path would give a boost to
> It's a decent amount of work to define one though... It's clearly not
> acceptable to just dump out the internal representation, as already discussed
> in this thread.
I totally agree that it should be a well-defined format that doesn't
leak stuff like endianness and alignment of the underlying
On Thu, Jun 23, 2022 at 9:06 PM Andres Freund wrote:
> It looks like there's quite a bit of low hanging fruits to optimize...
Yeah, if escapes and control characters are rare, adding an SSE2 fast
path would give a boost to json_lex_string: check 16 bytes at a time
for those chars (plus the
Hi,
On 2022-06-23 13:33:24 +0200, Jelte Fennema wrote:
> (reviving an old thread)
>
> On Thu, 23 Jun 2022 at 13:29, Merlin Moncure wrote:
> > I'll still stand other point I made though; I'd
> > really want to see some benchmarks demonstrating benefit over
> > competing approaches that work over
(attached is the flamegraph of the profile, in case others are interested)
On Thu, 23 Jun 2022 at 13:33, Jelte Fennema wrote:
>
> (reviving an old thread)
>
> On Thu, 23 Jun 2022 at 13:29, Merlin Moncure wrote:
> > I'll still stand other point I made though; I'd
> > really want to see some
(reviving an old thread)
On Thu, 23 Jun 2022 at 13:29, Merlin Moncure wrote:
> I'll still stand other point I made though; I'd
> really want to see some benchmarks demonstrating benefit over
> competing approaches that work over the current formats. That should
> frame the argument as to
On Fri, Nov 2, 2018 at 5:15 PM Andrew Dunstan
wrote:
> On 11/02/2018 05:20 PM, Andres Freund wrote:
> > Hi,
> >
> > On 2018-11-02 17:02:24 -0400, Andrew Dunstan wrote:
> >> On 11/02/2018 11:34 AM, Merlin Moncure wrote:
> >>> Binary format consuming applications already have to deal with these
>
On 2018-11-02 23:24:35 +0100, David Fetter wrote:
> On Wed, Oct 31, 2018 at 11:18:46AM -0400, Stephen Frost wrote:
> > Greetings,
> >
> > * Tom Lane (t...@sss.pgh.pa.us) wrote:
> > > Stephen Frost writes:
> > > > * Tom Lane (t...@sss.pgh.pa.us) wrote:
> > > >> I dunno, I do not think it's a
On Wed, Oct 31, 2018 at 11:18:46AM -0400, Stephen Frost wrote:
> Greetings,
>
> * Tom Lane (t...@sss.pgh.pa.us) wrote:
> > Stephen Frost writes:
> > > * Tom Lane (t...@sss.pgh.pa.us) wrote:
> > >> I dunno, I do not think it's a great idea to expose jsonb's internal
> > >> format to the world.
On 11/02/2018 05:20 PM, Andres Freund wrote:
Hi,
On 2018-11-02 17:02:24 -0400, Andrew Dunstan wrote:
On 11/02/2018 11:34 AM, Merlin Moncure wrote:
Binary format consuming applications already have to deal with these
kinds of issues. We already expose internal structures in the other
Hi,
On 2018-11-02 17:02:24 -0400, Andrew Dunstan wrote:
> On 11/02/2018 11:34 AM, Merlin Moncure wrote:
> >
> > Binary format consuming applications already have to deal with these
> > kinds of issues. We already expose internal structures in the other
> > functions -- not sure why jsonb is held
Hi,
On 2018-11-02 11:52:59 -0400, Tom Lane wrote:
> Andres' point about alignment is a pretty good one as well, if it applies
> here --- I don't recall just what internal alignment requirements jsonb
> has. We have not historically expected clients to have to deal with that.
Certainly looks
On 2018-11-02 10:34:07 -0500, Merlin Moncure wrote:
> On Wed, Oct 31, 2018 at 10:23 AM Andres Freund wrote:
> >
> > Hi,
> >
> > On 2018-10-31 11:13:13 -0400, Andrew Dunstan wrote:
> > > I agree that just sending a blob of the internal format isn't a great
> > > idea.
> >
> > It's entirely
On 11/02/2018 11:34 AM, Merlin Moncure wrote:
Binary format consuming applications already have to deal with these
kinds of issues. We already expose internal structures in the other
functions -- not sure why jsonb is held to a different standard. For
other data types where format changes
On Fri, Nov 2, 2018 at 2:34 PM Stephen Frost wrote:
> * Merlin Moncure (mmonc...@gmail.com) wrote:
> As for what language it's written in- I don't think that matters much.
> I'd very much expect it to be more performant to use binary if you're
> working in C, of course, but there's no point
Greetings,
* Merlin Moncure (mmonc...@gmail.com) wrote:
> On Fri, Nov 2, 2018 at 11:15 AM Stephen Frost wrote:
> > * Merlin Moncure (mmonc...@gmail.com) wrote:
> > > I'll still stand other point I made though; I'd
> > > really want to see some benchmarks demonstrating benefit over
> > >
On Fri, Nov 2, 2018 at 11:15 AM Stephen Frost wrote:
>
> Greetings,
>
> * Merlin Moncure (mmonc...@gmail.com) wrote:
> > On Fri, Nov 2, 2018 at 10:53 AM Tom Lane wrote:
> > > Andres' point about alignment is a pretty good one as well, if it applies
> > > here --- I don't recall just what
Greetings,
* Merlin Moncure (mmonc...@gmail.com) wrote:
> On Fri, Nov 2, 2018 at 10:53 AM Tom Lane wrote:
> > Andres' point about alignment is a pretty good one as well, if it applies
> > here --- I don't recall just what internal alignment requirements jsonb
> > has. We have not historically
On Fri, Nov 2, 2018 at 10:53 AM Tom Lane wrote:
> Merlin Moncure writes:
> > On Wed, Oct 31, 2018 at 10:23 AM Andres Freund wrote:
> >> It's entirely unacceptable afaict. Besides the whole "exposing
> >> internals" issue, it's also at least not endianess safe, depends on the
> >> local
Merlin Moncure writes:
> On Wed, Oct 31, 2018 at 10:23 AM Andres Freund wrote:
>> It's entirely unacceptable afaict. Besides the whole "exposing
>> internals" issue, it's also at least not endianess safe, depends on the
>> local alignment requirements (which differ both between platforms and
>>
On Wed, Oct 31, 2018 at 10:23 AM Andres Freund wrote:
>
> Hi,
>
> On 2018-10-31 11:13:13 -0400, Andrew Dunstan wrote:
> > I agree that just sending a blob of the internal format isn't a great idea.
>
> It's entirely unacceptable afaict. Besides the whole "exposing
> internals" issue, it's also at
On 11/02/2018 01:42 PM, Daniel Gustafsson wrote:
>> On 2 Nov 2018, at 04:21, Tom Lane wrote:
>
>> (In short, I remain unconvinced that we'd not be better off spending
>> our effort on making json_out faster...)
>
> Shooting wildly from the hip, isn't this a case where we can
> potentially
> On 2 Nov 2018, at 04:21, Tom Lane wrote:
> (In short, I remain unconvinced that we'd not be better off spending
> our effort on making json_out faster...)
Shooting wildly from the hip, isn't this a case where we can potentially
utilize the JIT infrastructure to speed it up?
cheers ./daniel
Greetings,
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Christian Ohler writes:
> > On Wed, Oct 31, 2018 at 7:22 AM Tom Lane wrote:
> >> If we're going to expose the
> >> internal format, let's just change the definition of the type's binary
> >> I/O format, thereby getting a win for purposes like
Christian Ohler writes:
> On Wed, Oct 31, 2018 at 7:22 AM Tom Lane wrote:
>> If we're going to expose the
>> internal format, let's just change the definition of the type's binary
>> I/O format, thereby getting a win for purposes like COPY BINARY as well.
> How would this work from the driver's
On Wed, Oct 31, 2018 at 7:22 AM Tom Lane wrote:
> If we're going to expose the
> internal format, let's just change the definition of the type's binary
> I/O format, thereby getting a win for purposes like COPY BINARY as well.
> We'd need to ensure that jsonb_recv could tell whether it was
Hi,
On 2018-10-31 11:13:13 -0400, Andrew Dunstan wrote:
> I agree that just sending a blob of the internal format isn't a great idea.
It's entirely unacceptable afaict. Besides the whole "exposing
internals" issue, it's also at least not endianess safe, depends on the
local alignment
Greetings,
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Stephen Frost writes:
> > * Tom Lane (t...@sss.pgh.pa.us) wrote:
> >> I dunno, I do not think it's a great idea to expose jsonb's internal
> >> format to the world. We intentionally did not do that when the type
> >> was first defined ---
On 10/31/2018 10:21 AM, Tom Lane wrote:
Stephen Frost writes:
* Tom Lane (t...@sss.pgh.pa.us) wrote:
I dunno, I do not think it's a great idea to expose jsonb's internal
format to the world. We intentionally did not do that when the type
was first defined --- that's why its binary I/O
Stephen Frost writes:
> * Tom Lane (t...@sss.pgh.pa.us) wrote:
>> I dunno, I do not think it's a great idea to expose jsonb's internal
>> format to the world. We intentionally did not do that when the type
>> was first defined --- that's why its binary I/O format isn't already
>> like this ---
Greetings,
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Kevin Van writes:
> > This patch adds a new function that allows callers to receive binary jsonb.
> > This change was proposed in the discussion here:
> >
Kevin Van writes:
> This patch adds a new function that allows callers to receive binary jsonb.
> This change was proposed in the discussion here:
> https://www.postgresql.org/message-id/CAOsiKEL7%2BKkV0C_hAJWxqwTg%2BPYVfiGPQ0yjFww7ECtqwBjb%2BQ%40mail.gmail.com
> and the primary motivation is to
This patch adds a new function that allows callers to receive binary jsonb.
This change was proposed in the discussion here:
https://www.postgresql.org/message-id/CAOsiKEL7%2BKkV0C_hAJWxqwTg%2BPYVfiGPQ0yjFww7ECtqwBjb%2BQ%40mail.gmail.com
and the primary motivation is to reduce database load by
34 matches
Mail list logo
