> Luke Lonergan wrote:
> > Bruce,
> > On 12/27/05 10:20 AM, "Bruce Momjian" <firstname.lastname@example.org> wrote:
> > > OK, original patch applied to HEAD and smaller version to 8.1.X, and
> > > regression test added, now attached.
> > Great, good catch.
> > Have you tested performance, before and after?
> > The only good way to test performance is using a fast enough I/O subsystem
> > that you are CPU-bound, which means >60MB/s of write speed.
> > I'd be happy to get you an account on one.
> I don't need to test performance because it is the same code, just with
> macros and the two functions merged. I do have an optimization for that
> loop but I saw no improvement so I didn't apply it. It was basically to
> advance the pointer in a tight look just checking for \r, \n, and \\,
> but it seems the larger loop isn't much slower than a tight one.
Here is the patch I was testing. I don't see any win on my hardware,
but it isn't a huge machine, so you might see an improvement on your
hardware, and if you do, we can consider applying it.
Bruce Momjian | http://candle.pha.pa.us
email@example.com | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073
RCS file: /cvsroot/pgsql/src/backend/commands/copy.c,v
retrieving revision 1.257
diff -c -c -r1.257 copy.c
*** src/backend/commands/copy.c 28 Dec 2005 03:25:32 -0000 1.257
--- src/backend/commands/copy.c 28 Dec 2005 03:39:42 -0000
*** 2207,2212 ****
--- 2207,2224 ----
need_data = false;
+ if (!cstate->encoding_embeds_ascii && !cstate->csv_mode)
+ char *p = copy_raw_buf + raw_buf_ptr;
+ char *e = copy_raw_buf + copy_buf_len;
+ while (p < e && *p != '\r' && *p != '\n' && *p != '\\')
+ prev_raw_ptr = raw_buf_ptr = p - copy_raw_buf;
/* OK to fetch a character */
prev_raw_ptr = raw_buf_ptr;
c = copy_raw_buf[raw_buf_ptr++];
---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not