Re: COPY fast parse patch

Neil,

Right; I really dislike the idea of having two separate code paths for
COPY. When you say this approach is "temporary", are you suggesting that
you intend to reimplement your changes as improvements/replacements of
the existing COPY code path rather than as a parallel code path?

====
My thoughts were -- see how the responses are, and if people think that this is a better way to go than replace the COPY parsing logic to the new one. The whole escaping discussion that goes on is something else, escapes could be implemented in either way, but the important thing I am trying to show is that there is a much faster way to parse the data instead of doing a char-by-char petch-examine-load.

> As a part of submitting this patch I also presented an argument for a use of
> a LOAD DATA command (in the NOLOGGING option thread). The points I made
> there are closely related to this message. There may be a valid argument
> that most of the points I raised could be implemented in the COPY code
> instead of a LOAD DATA command

I'm definitely not keen to see a new "LOAD DATA" command.

====
It seems that most people don't :-) I can see valid arguments to both having it and not having it.

> But that may not be a good idea for some and will also be problematic
> for backwards compatiability.

In what way would the performance improvements to COPY be backward
incompatible with the existing COPY behaviour?

====
That comment was in respect to the escape logic. You can regard it as irrelevant for now as long as the escape discussion goes on in parallel.

Alon.

-Neil

On Thu, 2005-06-02 at 00:53 -0400, Alon Goldshuv wrote:
> My thoughts were -- see how the responses are, and if people think
> that this is a better way to go than replace the COPY parsing logic to
> the new one.

If the new approach to parsing can handle all the cases that the old
approach can handle (WRT CSV, binary, encoding conversion and the like)
and is faster to boot, I don't see a reason not to replace the current
approach with something derived from your patch.

-Neil

FYI - we're prepping a proposal for just that. Stay tuned for Alon's
proposal.

Luke

On 6/1/05 11:43 PM, "Neil Conway" <neilc(at)samurai(dot)com> wrote:

> On Thu, 2005-06-02 at 00:53 -0400, Alon Goldshuv wrote:
>> My thoughts were -- see how the responses are, and if people think
>> that this is a better way to go than replace the COPY parsing logic to
>> the new one.
>
> If the new approach to parsing can handle all the cases that the old
> approach can handle (WRT CSV, binary, encoding conversion and the like)
> and is faster to boot, I don't see a reason not to replace the current
> approach with something derived from your patch.
>
> -Neil
>
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 8: explain analyze is your friend
>