| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Andrew Gierth <andrew(at)tao11(dot)riddles(dot)org(dot)uk> |
| Cc: | Andres Freund <andres(at)anarazel(dot)de>, pgsql-hackers(at)lists(dot)postgresql(dot)org, Thomas Munro <thomas(dot)munro(at)enterprisedb(dot)com>, Alexander Kuzmenkov <a(dot)kuzmenkov(at)postgrespro(dot)ru> |
| Subject: | Re: Performance improvements for src/port/snprintf.c |
| Date: | 2018-10-06 03:16:13 |
| Message-ID: | 13967.1538795773@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Andrew Gierth <andrew(at)tao11(dot)riddles(dot)org(dot)uk> writes:
> So here's a thing: I finally got to doing my performance tests for using
> the Ryu float output code in float[48]out.
> Ryu is so blazing fast that with it, COPY of a table with 2million rows
> of 12 random float8 columns (plus id) becomes FASTER in text mode than
> in binary mode (rather than ~5x slower):
Oh yeah? Where's the code for this?
> (And yes, I've double-checked the results and they look correct, other
> than the formatting differences. COPY BINARY seems to have a bit more
> overhead than text mode, even for just doing integers, I don't know
> why.)
The per-column overhead is more (length word vs delimiter) and I think
the APIs for send/recv functions are potentially a bit less efficient
too.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Andrew Gierth | 2018-10-06 03:36:51 | Re: Performance improvements for src/port/snprintf.c |
| Previous Message | Andrew Gierth | 2018-10-06 03:10:00 | Re: Performance improvements for src/port/snprintf.c |