Re: Faster str to int conversion (was Table with large number of intcolumns, very slow COPY FROM)
| От | Andres Freund |
|---|---|
| Тема | Re: Faster str to int conversion (was Table with large number of intcolumns, very slow COPY FROM) |
| Дата | |
| Msg-id | 20180707200158.wpqkd7rjr4jxq5g7@alap3.anarazel.de обсуждение исходный текст |
| Ответ на | Faster str to int conversion (was Table with large number of intcolumns, very slow COPY FROM) (Andres Freund <andres@anarazel.de>) |
| Ответы |
Re: Faster str to int conversion (was Table with large number of intcolumns, very slow COPY FROM)
Re: Faster str to int conversion (was Table with large number of intcolumns, very slow COPY FROM) |
| Список | pgsql-hackers |
Hi, On 2017-12-08 13:44:37 -0800, Andres Freund wrote: > On 2017-12-08 10:17:34 -0800, Andres Freund wrote: > > the strtoll is libc functionality triggered by pg_atoi(), something I've > > seen show up in numerous profiles. I think it's probably time to have > > our own optimized version of it rather than relying on libcs. > > Attached is a hand-rolled version. After quickly hacking up one from > scratch, I noticed we already kind of have one for int64 (scanint8), so > I changed the structure of this one to be relatively similar. > > It's currently using the overflow logic from [1], but that's not > fundamentally required, we could rely on fwrapv for this one too. > > This one improves performance of the submitted workload from 1223.950ms > to 1020.640ms (best of three). The profile's shape changes quite > noticeably: FWIW, here's a rebased version of this patch. Could probably be polished further. One might argue that we should do a bit more wide ranging changes, to convert scanint8 and pg_atoi to be also unified. But it might also just be worthwhile to apply without those, given the performance benefit. Anybody have an opinion on that? Greetings, Andres Freund
Вложения
В списке pgsql-hackers по дате отправления: