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" <[EMAIL PROTECTED]> 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 bet
Andrew,
> OK ... that seems fair enough. The next question is where the data being
> loaded comes from? pg_dump? How does load speed compare with using COPY's
> binary mode?
Oddly, our tests in the past have shown that binary is actually slower.
Luke
---(end of broadca
Luke Lonergan said:
> Andrew,
>
>> I will be the first to admit that there are probably some very good
>> possibilities for optimisation of this code. My impression though has
>> been that in almost all cases it's fast enough anyway. I know that on
>> some very modest hardware I have managed to loa
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 han
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 tho
Andrew,
> I will be the first to admit that there are probably some very good
> possibilities for optimisation of this code. My impression though has been
> that in almost all cases it's fast enough anyway. I know that on some very
> modest hardware I have managed to load a 6m row TPC line-items t
Neil Conway said:
> On Wed, 2005-06-01 at 16:34 -0700, Alon Goldshuv wrote:
>> 1) The patch includes 2 parallel parsing code paths. One is the
>> regular COPY path that we all know, and the other is the improved one
>> that I wrote. This is only temporary, as there is a lot of code
>> duplication
>
On Wed, 2005-06-01 at 16:34 -0700, Alon Goldshuv wrote:
> 1) The patch includes 2 parallel parsing code paths. One is the regular COPY
> path that we all know, and the other is the improved one that I wrote. This
> is only temporary, as there is a lot of code duplication
Right; I really dislike th
Alon Goldshuv wrote:
> 5) Data integrity and escaping improvements. Treats all characters as data
> (unless it's an escaped delim or EOL) and therefore data
> integrity is preserved. However, some people that already got
> used to the postgres COPY escaping way may want to keep it. They could do so
