Heikki Linnakangas <heikki.linnakan...@enterprisedb.com> writes: > * we perform possible encoding conversion early, one input block at a > time, rather than after splitting the input into lines. This allows us > to assume in the later stages that the data is in server encoding, > allowing us to search for the '\n' byte without worrying about > multi-byte characters.
Seems reasonable, although the need to deal with multibyte characters crossing a block boundary injects some ugliness that wasn't there before. > * instead of the byte-at-a-time loop in CopyReadLineText(), use memchr() > to find the next NL/CR character. This is where the speedup comes from. That seems like the speedup, if any, would be extremely platform-dependent. What have you tested on? > There's a small fly in the ointment: the patch won't recognize backslash > followed by a linefeed as an escaped linefeed. I think we should simply > drop support for that. I think this is likely to break apps that have worked for years. I can't get excited about doing that in return for an "0-10%" speedup that might only materialize on some platforms. If the numbers were better, it'd be worth paying that price, but ... > It's not strictly necessary, but how about dropping support for the old > COPY protocol, and the EOF marker \. while we're at it? It would allow > us to drop some code, making the remaining code simpler, and reduce the > testing effort. Thoughts on that? Again, I think the threshold requirement for breaking compatibility needs to be a lot higher than this. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers