From: | "Nigel J(dot) Andrews" <nandrews(at)investsystems(dot)co(dot)uk> |
---|---|
To: | Jan Wieck <JanWieck(at)Yahoo(dot)com> |
Cc: | "alex b(dot)" <mailinglists1(at)gmx(dot)de>, Postgresql General <pgsql-general(at)postgresql(dot)org> |
Subject: | Re: images in database |
Date: | 2003-04-03 13:13:22 |
Message-ID: | Pine.LNX.4.21.0304031409150.12600-100000@ponder.fairway2k.co.uk |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
On Thu, 3 Apr 2003, Jan Wieck wrote:
> "Nigel J. Andrews" wrote:
> > B64 would still require a bytea storage type to avoid any character encoding
> > issue between client and server though, right?
>
> I don't think so, since it uses characters from the 7-Bit ASCII set
> exclusively and IIRC those map to the same codes in almost every
> encoding except EBCDIC (though, I'm not an encoding expert).
>
> What might have slowed down bytea as it would text is TOAST's attempt to
> compress the data. As image data usually is compressed already (if not
> using PPM or such), this will be a waste of time. For that reason alone,
> TOAST offers you to disable the compression attempt on a per attribute
> base.
>
Now that is interesting, I didn't try that. I might have another test run to
see what difference it makes, if I find the time.
There was a definite relationship between data size increase through escaping
and speed. Some of which would be down to the escape/unescape process itself,
some down to the transmission between client and server and then there'd be
some impact from the server's operations as well. I didn't quantify the split.
--
Nigel J. Andrews
From | Date | Subject | |
---|---|---|---|
Next Message | Marc Drouin | 2003-04-03 13:14:46 | Re: Trigger functions |
Previous Message | Jan Wieck | 2003-04-03 12:59:21 | Re: images in database |