Re: Client-side compression

Поиск
Список
Период
Сортировка
От Jasen Betts
Тема Re: Client-side compression
Дата
Msg-id h1t5a7$sde$2@reversiblemaps.ath.cx
обсуждение исходный текст
Ответ на Client-side compression  (Rob Sargent <robjsargent@gmail.com>)
Список pgsql-sql
On 2009-06-23, Rob Sargent <robjsargent@gmail.com> wrote:
>
> Not sure if this belongs here or on the admin or performance list.  
> Apologies if so. (And this may be a second posting as the first was from 
> an un-registered account.  Further apologies)
>
> My assumption is that any de/compression done by postgres would be 
> server-side.

there may already be compression of the communication stream (probably not on
unix sockets)

> We're considering minimizing bandwidth utilization by using client-side 
> compression on a column value that will typically be multi-megabyte in 
> size.  We would use ALTER TABLE SET STORAGE EXTERNAL to prevent the 
> server from un-necessary compression.
>
> Is this generally worthwhile?  I haven't found any thread on the subject 
> of client-side compress so any pointer more than welcome.

we recently switched from uncompressed pixmaps to JPEG data for some stored 
images. we have not tested performance but have certainly not noticed a 
decrease in performance.

> Is there a great penalty for a query which delves into the value, given 
> that the server will not be aware it's compressed?  I assume we're 
> pretty much on our own to prevent such actions (i.e. the app can never 
> query against this column via sql).

It just looks like data to the server.


В списке pgsql-sql по дате отправления:

Предыдущее
От: Harald Fuchs
Дата:
Сообщение: Re: Composite primary keys
Следующее
От: Filip Rembiałkowski
Дата:
Сообщение: Re: Client-side compression