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: | Raw Message | Whole Thread | 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 |