Received: from maia.hub.org (unknown [200.46.204.183]) by mail.postgresql.org (Postfix) with ESMTP id 68093635260 for ; Mon, 2 Nov 2009 06:24:20 -0400 (AST) Received: from mail.postgresql.org ([200.46.204.86]) by maia.hub.org (mx1.hub.org [200.46.204.183]) (amavisd-maia, port 10024) with ESMTP id 59421-04-3 for ; Mon, 2 Nov 2009 10:24:10 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from s21sec.com (mail.s21sec.com [88.84.64.3]) by mail.postgresql.org (Postfix) with ESMTP id 56056907A2F for ; Mon, 2 Nov 2009 05:51:11 -0400 (AST) Received: from PAM-INV-007.s21sec.com (178.Red-88-2-149.staticIP.rima-tde.net [88.2.149.178]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by s21sec.com (Postfix) with ESMTPSA id 45474558AA6; Mon, 2 Nov 2009 10:53:49 +0100 (CET) X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 02 Nov 2009 10:51:06 +0100 To: Robert Haas From: Eduardo Morras Subject: Re: Compression in PG Cc: pgsql-performance@postgresql.org In-Reply-To: <603c8f070911012024q26bd2b2aw9da2cef4d8face0f@mail.gmail.co m> References: <234efe30911010651k6cf3d398t9d61e560d57b52b7@mail.gmail.com> <162867790911010656m37b315dbp41761a014745b9e4@mail.gmail.com> <234efe30911010853k1908b6a6kdb1ebcdbc4c22691@mail.gmail.com> <603c8f070911012024q26bd2b2aw9da2cef4d8face0f@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Message-Id: <20091102095349.45474558AA6@s21sec.com> X-Virus-Scanned: Maia Mailguard 1.0.1 X-Spam-Status: No, hits=0.001 tagged_above=-10 required=5 tests=BAYES_50=0.001 X-Spam-Level: X-Archive-Number: 200911/9 X-Sequence-Number: 36177 At 05:24 02/11/2009, you wrote: >The only reason I can think of for wanting to compress very small >datums is if you have a gajillion of them, they're highly >compressible, and you have extra CPU time coming out of your ears. In >that case - yeah, you might want to think about pre-compressing them >outside of Pg. If you're doing this for some other reason you could >probably get some better advice if you explain what it is... > >...Robert There is another reason. If you compress (lossless) all the small text= datums with the same algorithm, you get unique and smaller representations= of the text that can be used as primary unique keys. You can see it like a= variable length hashing algorithm. Depending the compression method (f.ex. static huffman) you can compare 2= texts using only the compressed versions or sort them faster. This cannot= be done with the actual LZ algorithm. -------------------------------- Eduardo Morr=E1s Gonz=E1lez Dept. I+D+i e-Crime Vigilancia Digital S21sec Labs Tlf: +34 902 222 521 M=F3vil: +34 555 555 555=20 www.s21sec.com, blog.s21sec.com=20 Salvo que se indique lo contrario, esta informaci=F3n es CONFIDENCIAL y contiene datos de car=E1cter personal que han de ser tratados conforme a la legislaci=F3n vigente en materia de protecci=F3n de datos. Si usted no es destinatario original de este mensaje, le comunicamos que no est=E1= autorizado a revisar, reenviar, distribuir, copiar o imprimir la informaci=F3n en =E9l contenida y le rogamos que proceda a borrarlo de sus sistemas. Kontrakoa adierazi ezean, posta elektroniko honen barruan doana ISILPEKO informazioa da eta izaera pertsonaleko datuak dituenez, indarrean dagoen datu pertsonalak babesteko legediaren arabera tratatu beharrekoa. Posta honen hartzaile ez zaren kasuan, jakinarazten dizugu baimenik ez duzula bertan dagoen informazioa aztertu, igorri, banatu, kopiatu edo inprimatzeko. Hortaz, erregutzen dizugu posta hau zure sistemetatik berehala ezabatzea.=20 Antes de imprimir este mensaje valora si verdaderamente es necesario. De esta forma contribuimos a la preservaci=F3n del Medio Ambiente.=20