On 26/08/10 22:16, Tom Lane wrote:
Heikki Linnakangas<heikki.linnakan...@enterprisedb.com> writes:
* 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?
Only on my 32-bit Intel Linux laptop.
If anyone out there has more interesting platforms to test on, that
would be appreciated.
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 ...
Ok. If we have to, we can keep that, it just requires more programming.
After searching for a \n, we can peek at the previous byte to check if
it's a backslash (and if it is, the one before that to see if it's a
backslash too, and so forth until we find a non-backslash).
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
