From: | "alex b(dot)" <mailinglists1(at)gmx(dot)de> |
---|---|
To: | "Nigel J(dot) Andrews" <nandrews(at)investsystems(dot)co(dot)uk> |
Cc: | Postgresql General <pgsql-general(at)postgresql(dot)org> |
Subject: | Re: images in database |
Date: | 2003-04-03 17:23:40 |
Message-ID: | 3E8C6E1C.50206@gmx.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
Nigel J. Andrews wrote:
> 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.
>
>
well, I thank all of you guys for answering my question!! ;)
I appreciate it very much!
cheers,
alex
From | Date | Subject | |
---|---|---|---|
Next Message | Dennis Gearon | 2003-04-03 17:31:09 | Re: this date format thing. |
Previous Message | scott.marlowe | 2003-04-03 17:15:42 | Re: Postgresql capabilities question |