Hi,
In <20240219195351.5vy7cdl3wxia6...@awork3.anarazel.de>
"Re: Why is pq_begintypsend so slow?" on Mon, 19 Feb 2024 11:53:51 -0800,
Andres Freund wrote:
>> I don't have a strong opinion how to implement this
>> optimization as I said above. It seems that you
Hi,
On 2024-02-19 10:02:52 +0900, Sutou Kouhei wrote:
> In <20240218200906.zvihkrs46yl2j...@awork3.anarazel.de>
> "Re: Why is pq_begintypsend so slow?" on Sun, 18 Feb 2024 12:09:06 -0800,
> Andres Freund wrote:
>
> >> [1]
> >&
Hi,
In <20240218200906.zvihkrs46yl2j...@awork3.anarazel.de>
"Re: Why is pq_begintypsend so slow?" on Sun, 18 Feb 2024 12:09:06 -0800,
Andres Freund wrote:
>> [1]
>> https://www.postgresql.org/message-id/flat/20240215.153421.9688810378
On Sun, Feb 18, 2024 at 12:09:06PM -0800, Andres Freund wrote:
> On 2024-02-18 17:38:09 +0900, Sutou Kouhei wrote:
>> @@ -1966,7 +1992,7 @@ CopyReadBinaryAttribute(CopyFromState cstate, FmgrInfo
>> *flinfo,
>> if (fld_size == -1)
>> {
>> *isnull = true;
>> -
Hi,
On 2024-02-18 17:38:09 +0900, Sutou Kouhei wrote:
> In <20240218015955.rmw5mcmobt5hb...@awork3.anarazel.de>
> "Re: Why is pq_begintypsend so slow?" on Sat, 17 Feb 2024 17:59:55 -0800,
> Andres Freund wrote:
>
> > v3-0008-wip-make-in-out-send-
Hi,
In <20240218015955.rmw5mcmobt5hb...@awork3.anarazel.de>
"Re: Why is pq_begintypsend so slow?" on Sat, 17 Feb 2024 17:59:55 -0800,
Andres Freund wrote:
> v3-0008-wip-make-in-out-send-recv-calls-in-copy.c-cheaper.patch
It seems that this is an alternative approach
Hi,
I was reminded of the patchset I had posted in this thread by
https://postgr.es/m/679d5455cbbb0af667ccb753da51a475bae1eaed.camel%40cybertec.at
On 2020-07-31 13:35:43 -0400, Robert Haas wrote:
> On Fri, Jul 31, 2020 at 1:00 PM Andres Freund wrote:
> > > Perhaps we could add a comment about
On Fri, Jul 31, 2020 at 1:00 PM Andres Freund wrote:
> > Perhaps we could add a comment about this, e.g.
> > Marking these pointers with pg_restrict tells the compiler that str
> > and str->data can't overlap, which may allow the compiler to optimize
> > better when this code is inlined. For
Hi,
On 2020-07-31 12:28:04 -0400, Robert Haas wrote:
> On Fri, Jul 31, 2020 at 11:50 AM Andres Freund wrote:
> > I hope the above makes this make sene now? It's about subsequent uses of
> > the StringInfo, rather than the body of resetStringInfo itself.
>
> That does make sense, except that
>
On Fri, Jul 31, 2020 at 11:50 AM Andres Freund wrote:
> I hope the above makes this make sene now? It's about subsequent uses of
> the StringInfo, rather than the body of resetStringInfo itself.
That does make sense, except that
https://en.cppreference.com/w/c/language/restrict says "During each
Hi,
On 2020-07-31 11:14:46 -0400, Robert Haas wrote:
> Here is some review for the first few patches in this series.
Thanks!
> I am generally in favor of applying 0001-0003 no matter what else we
> decide to do here. However, as might be expected, I have a few
> questions and comments.
>
>
Here is some review for the first few patches in this series.
I am generally in favor of applying 0001-0003 no matter what else we
decide to do here. However, as might be expected, I have a few
questions and comments.
Regarding 0001:
I dislike the name initStringInfoEx() because we do not use
On Tue, Jun 2, 2020 at 9:56 PM Andres Freund wrote:
> I don't know what the best non-gross solution for the overhead of the
> out/send functions is. There seems to be at least the following
> major options (and a lots of variants thereof):
>
> 1) Just continue to incur significant overhead for
On Tue, Jun 9, 2020 at 3:23 PM Andres Freund wrote:
> ISTM that it'd be pretty broken if it could happen. We cannot have two
> different parts of the system send messages to the client
> independently. The protocol is pretty stateful...
There's a difference between building messages concurrently
Hi,
On 2020-06-09 11:46:09 -0400, Robert Haas wrote:
> On Wed, Jun 3, 2020 at 2:10 PM Andres Freund wrote:
> > Why do we need multiple buffers? ISTM we don't want to just send
> > messages at endmsg() time, because that implies unnecessary syscall
> > overhead. Nor do we want to imply the
On Wed, Jun 3, 2020 at 2:10 PM Andres Freund wrote:
> Why do we need multiple buffers? ISTM we don't want to just send
> messages at endmsg() time, because that implies unnecessary syscall
> overhead. Nor do we want to imply the overhead of the copy from the
> message buffer to the network
Hi,
On 2020-06-03 11:30:42 -0400, Robert Haas wrote:
> I too have seen recent benchmarking data where this was a big problem.
> Basically, you need a workload where the server doesn't have much or
> any actual query processing to do, but is just returning a lot of
> stuff to a really fast client
On Tue, Jun 2, 2020 at 9:56 PM Andres Freund wrote:
> The biggest problem after that is that we waste a lot of time memcpying
> stuff around repeatedly. There is:
> 1) send function: datum -> per datum stringinfo
> 2) printtup: per datum stringinfo -> per row stringinfo
> 3) socket_putmessage:
Hi,
On 2020-05-18 12:38:05 -0400, Tom Lane wrote:
> Andres Freund writes:
> >> FWIW, I've also observed, in another thread (the node func generation
> >> thing [1]), that inlining enlargeStringInfo() helps a lot, especially
> >> when inlining some of its callers. Moving e.g. appendStringInfo()
Ranier Vilela writes:
> Again, I see problems with the types declared in Postgres.
> 1. pq_sendint32 (StringInfo buf, uint32 i)
> 2. extern void pq_sendbytes (StringInfo buf, const char * data, int
> datalen);
We could spend the next ten years cleaning up minor discrepancies
like that, and have
Em seg., 18 de mai. de 2020 às 13:38, Tom Lane escreveu:
> Andres Freund writes:
> >> FWIW, I've also observed, in another thread (the node func generation
> >> thing [1]), that inlining enlargeStringInfo() helps a lot, especially
> >> when inlining some of its callers. Moving e.g.
Andres Freund writes:
>> FWIW, I've also observed, in another thread (the node func generation
>> thing [1]), that inlining enlargeStringInfo() helps a lot, especially
>> when inlining some of its callers. Moving e.g. appendStringInfo() inline
>> allows the compiler to sometimes optimize away the
Hi,
On 2020-01-13 15:18:04 -0800, Andres Freund wrote:
> On 2020-01-11 22:32:45 -0500, Tom Lane wrote:
> > I wrote:
> > > I saw at this point that the remaining top spots were
> > > enlargeStringInfo and appendBinaryStringInfo, so I experimented
> > > with inlining them (again, see patch below).
Hi,
On 2020-01-11 22:32:45 -0500, Tom Lane wrote:
> I wrote:
> > I saw at this point that the remaining top spots were
> > enlargeStringInfo and appendBinaryStringInfo, so I experimented
> > with inlining them (again, see patch below). That *did* move
> > the needle: down to 72691 ms, or 20%
I wrote:
> I saw at this point that the remaining top spots were
> enlargeStringInfo and appendBinaryStringInfo, so I experimented
> with inlining them (again, see patch below). That *did* move
> the needle: down to 72691 ms, or 20% better than HEAD.
Oh ... marking the test in the inline part of
David Fetter writes:
> On Sat, Jan 11, 2020 at 03:19:37PM -0500, Tom Lane wrote:
>> Jeff Janes writes:
>>> I saw that the hotspot was pq_begintypsend at 20%, which was twice the
>>> percentage as the next place winner (AllocSetAlloc).
>> I'd be inclined to replace the appendStringInfoCharMacro
On Sat, Jan 11, 2020 at 03:19:37PM -0500, Tom Lane wrote:
> Jeff Janes writes:
> > I saw that the hotspot was pq_begintypsend at 20%, which was twice the
> > percentage as the next place winner (AllocSetAlloc).
>
> Weird.
>
> > Why is this such a bottleneck?
>
> Not sure, but it seems like a
Jeff Janes writes:
> I saw that the hotspot was pq_begintypsend at 20%, which was twice the
> percentage as the next place winner (AllocSetAlloc).
Weird.
> Why is this such a bottleneck?
Not sure, but it seems like a pretty dumb way to push the stringinfo's
len forward. We're reading/updating
28 matches
Mail list logo
