| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Greg Stark <gsstark(at)mit(dot)edu> |
| Cc: | pgsql-hackers(at)postgresql(dot)org |
| Subject: | Re: type recv/send functions |
| Date: | 2006-05-30 03:42:36 |
| Message-ID: | 19509.1148960556@sss.pgh.pa.us |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Greg Stark <gsstark(at)mit(dot)edu> writes:
> "both return something" seems like an odd axis to measure.
> In one case it's given pointer to the entire message, picks out the piece it's
> interested in and advances the cursor.
This is just a trivial optimization compared to being handed a bytea
input, which would be the "clean" version. (I had originally thought
we could fake a bytea input without any copying, much as is done in the
text input path, but that fails on machines that are persnickety about
alignment: the "bytea" length word might not be word-aligned depending
on message contents.)
> What I'm pondering here is that the extra copy to construct the bytea for
> every single data type being output seems like it would be a pretty big
> contribution to the complaint that postgres takes too much cpu in cases that
> should be entirely i/o bound.
Since approximately zero percent of the people making that complaint are
using binary output, I don't think it matters.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Marko Kreen | 2006-05-30 07:44:31 | Re: Inefficient bytea escaping? |
| Previous Message | Greg Stark | 2006-05-30 03:33:17 | Re: type recv/send functions |