Thread: Re: [PERFORM] COPY FROM performance improvements

Re: [PERFORM] COPY FROM performance improvements

From
Tom Lane
Date:
"Alon Goldshuv" <agoldshuv@greenplum.com> writes:
>> This patch appears to reverse out the most recent committed changes in
>> copy.c.

> Which changes do you refer to? I thought I accommodated all the recent
> changes (I recall some changes to the tupletable/tupleslot interface, HEADER
> in cvs, and hex escapes and maybe one or 2 more). What did I miss?

The latest touch of copy.c, namely this patch:

2005-07-10 17:13  tgl

    * doc/src/sgml/ref/create_type.sgml, src/backend/commands/copy.c,
    src/backend/commands/typecmds.c, src/backend/tcop/fastpath.c,
    src/backend/tcop/postgres.c, src/backend/utils/adt/arrayfuncs.c,
    src/backend/utils/adt/date.c, src/backend/utils/adt/numeric.c,
    src/backend/utils/adt/rowtypes.c,
    src/backend/utils/adt/timestamp.c, src/backend/utils/adt/varbit.c,
    src/backend/utils/adt/varchar.c, src/backend/utils/adt/varlena.c,
    src/backend/utils/mb/mbutils.c, src/include/catalog/catversion.h,
    src/include/catalog/pg_proc.h,
    src/test/regress/expected/type_sanity.out,
    src/test/regress/sql/type_sanity.sql: Change typreceive function
    API so that receive functions get the same optional arguments as
    text input functions, ie, typioparam OID and atttypmod.  Make all
    the datatypes that use typmod enforce it the same way in typreceive
    as they do in typinput.  This fixes a problem with failure to
    enforce length restrictions during COPY FROM BINARY.

It was rather obvious, given that the first chunk of the patch backed up
the file's CVS version stamp from 1.247 to 1.246 :-(

            regards, tom lane

Re: [PERFORM] COPY FROM performance improvements

From
"Alon Goldshuv"
Date:
Tom,

Thanks for pointing it out. I made the small required modifications to match
copy.c version 1.247 and sent it to -patches list. New patch is V16.

Alon.


On 8/1/05 7:51 PM, "Tom Lane" <tgl@sss.pgh.pa.us> wrote:

> "Alon Goldshuv" <agoldshuv@greenplum.com> writes:
>>> This patch appears to reverse out the most recent committed changes in
>>> copy.c.
>
>> Which changes do you refer to? I thought I accommodated all the recent
>> changes (I recall some changes to the tupletable/tupleslot interface, HEADER
>> in cvs, and hex escapes and maybe one or 2 more). What did I miss?
>
> The latest touch of copy.c, namely this patch:
>
> 2005-07-10 17:13  tgl
>
> * doc/src/sgml/ref/create_type.sgml, src/backend/commands/copy.c,
> src/backend/commands/typecmds.c, src/backend/tcop/fastpath.c,
> src/backend/tcop/postgres.c, src/backend/utils/adt/arrayfuncs.c,
> src/backend/utils/adt/date.c, src/backend/utils/adt/numeric.c,
> src/backend/utils/adt/rowtypes.c,
> src/backend/utils/adt/timestamp.c, src/backend/utils/adt/varbit.c,
> src/backend/utils/adt/varchar.c, src/backend/utils/adt/varlena.c,
> src/backend/utils/mb/mbutils.c, src/include/catalog/catversion.h,
> src/include/catalog/pg_proc.h,
> src/test/regress/expected/type_sanity.out,
> src/test/regress/sql/type_sanity.sql: Change typreceive function
> API so that receive functions get the same optional arguments as
> text input functions, ie, typioparam OID and atttypmod.  Make all
> the datatypes that use typmod enforce it the same way in typreceive
> as they do in typinput.  This fixes a problem with failure to
> enforce length restrictions during COPY FROM BINARY.
>
> It was rather obvious, given that the first chunk of the patch backed up
> the file's CVS version stamp from 1.247 to 1.246 :-(
>
> regards, tom lane
>