Re: Why is pq_begintypsend so slow?
От | David Fetter |
---|---|
Тема | Re: Why is pq_begintypsend so slow? |
Дата | |
Msg-id | 20200112014107.GC32763@fetter.org обсуждение исходный текст |
Ответ на | Re: Why is pq_begintypsend so slow? (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Why is pq_begintypsend so slow?
|
Список | pgsql-hackers |
On Sat, Jan 11, 2020 at 03:19:37PM -0500, Tom Lane wrote: > 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? Please find attached a patch that does it both of the things you suggested. Best, David. -- David Fetter <david(at)fetter(dot)org> http://fetter.org/ Phone: +1 415 235 3778 Remember to vote! Consider donating to Postgres: http://www.postgresql.org/about/donate
Вложения
В списке pgsql-hackers по дате отправления: