From: | Andrew Dunstan <andrew(at)dunslane(dot)net> |
---|---|
To: | Heikki Linnakangas <heikki(at)enterprisedb(dot)com> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Simon Riggs <simon(at)2ndquadrant(dot)com>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Commit Fest (was Re: Sort Refinement) |
Date: | 2008-03-21 19:21:11 |
Message-ID: | 47E40AA7.9010906@dunslane.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Heikki Linnakangas wrote:
> Tom Lane wrote:
>> Andrew Dunstan <andrew(at)dunslane(dot)net> writes:
>>> There is your CopyReadLineText speedup, but I think there are too
>>> many open questions on it, e.g.:
>>> ...
>>> So I suggest we take it out of the queue for now and kick it back to
>>> you.
>>
>> Per my comments just now, the question is whether it's been adequately
>> reviewed or still needs some attention from the community. If we think
>> the ball's entirely in Heikki's court on it, then we're done with it
>> until he comes back with a new version (or evidence showing it's good
>> as-is).
>
> I'm not expecting any more review in this commit fest.
>
> My plan is to try special-casing the usual case of text-mode in a non
> ASCII-embedding encoding (one that can be used as server encoding), by
> using memchr() to find end of line first, and then scanning back from
> there to count preceding backslashes. That requires some refactoring,
> but should avoid the performance penalty when there's plenty of
> backslashes.
>
> Of course, if anyeone has better ideas, please speak up!
>
That won't work for CSV mode, of course, which leaves us with trying to
refine your previous solution in that case.
cheers
andrew
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 2008-03-21 19:34:22 | Re: [hensa22@yahoo.es: Re: [pgsql-es-ayuda] SLL error 100% cpu] |
Previous Message | Heikki Linnakangas | 2008-03-21 19:01:03 | Re: Commit Fest (was Re: Sort Refinement) |