Re: Why is pq_begintypsend so slow?
От | Tom Lane |
---|---|
Тема | Re: Why is pq_begintypsend so slow? |
Дата | |
Msg-id | 31795.1578773977@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Why is pq_begintypsend so slow? (Jeff Janes <jeff.janes@gmail.com>) |
Ответы |
Re: Why is pq_begintypsend so slow?
|
Список | pgsql-hackers |
Jeff Janes <jeff.janes@gmail.com> 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 the len word in each line, and if your perf measurements are to be believed, it's the re-fetches of the len values that are bottlenecked --- maybe your CPU isn't too bright about that? The bytes of the string value are getting written twice too, thanks to uselessly setting up a terminating nul each time. I'd be inclined to replace the appendStringInfoCharMacro calls with appendStringInfoSpaces(buf, 4) --- I don't think we care exactly what is inserted into those bytes at this point. And maybe appendStringInfoSpaces could stand some micro-optimization, too. Use a memset and a single len adjustment, perhaps? regards, tom lane
В списке pgsql-hackers по дате отправления: