On Mon, 15 Feb 2016 18:06:09 -0300 Alvaro Herrera <alvhe...@2ndquadrant.com> wrote:
> Eduardo Morras escribió: > > On Fri, 12 Feb 2016 09:43:52 -0300 > > Alvaro Herrera <alvhe...@2ndquadrant.com> wrote: > > > > > En realidad esas no son las preguntas que tenemos pendientes > > > ahora. Esas que propones ya se han discutido, y algoritmos como > > > lz4 y Snappy otros se han mencionado varias veces. El problema > > > pendiente es cómo permitir nuevos algoritmos de compresión en el > > > sistema. Mira por ejemplo este hilo: > > > > > > http://www.postgresql.org/message-id/flat/20130614230142.gc19...@awork2.anarazel.de > > > > > > y quizás este: > > > https://www.postgresql.org/message-id/CAPpHfdsdTA5uZeq6MNXL5ZRuNx%2BSig4ykWzWEAfkC6ZKMDy6%3DQ%40mail.gmail.com > > > > Comprendido, el problema es que no hay sitio para codificar que > > algoritmo de compresion se usa a nivel de toast. > > Si, pero también: > > 1. no hay consenso respecto del tema patentes. Los más conservadores > no quieren meterse en líos por posibles patentes que puedan existir. La mayor parte o bien nunca se han patentado (huffman, bwt), o bien las patentes han expirado o nunca se han aplicado(arithmetic coding, dmc, ppm, hash en lz77, deflate/zlib/gzip, rle). Es cierto que hay hay algoritmos en un claro oscuro (CM/ContextMixing, ROLZ, derivaciones de ppm/dmc), pero no necesarios para implementar uno. Ten en cuenta que estoy metiendo en el mismo saco, algoritmos de compresion y modelos de datos. > 2. ¿qué sucede si instalas un módulo X que permite compresión con > algoritmo XYZ, actualizas datos y después bajas la BD y la levantas > sin ese módulo? Si bajas la BD y la levantas sin ese modulo, sigues pudiendo acceder a los datos, pero no a la informacion, independientemente de que algoritmo de compresion hayas usado, ya que es el modulo XYZ el que sabe interpretar dichos datos. Sigues pudiendo hacer backups, borrar tuplas, consultas genericas, (select count(*) from table1) etc.. pero no hacer una consulta sobre una informacion especifica (select avg(c1) from table1) Los algoritmos de compresion 'pesan' muy poco en el ejecutable final y se pueden incluir en el core. No hace falta implementar muchos en core (1 o 2), pero si hacer que modulos que manejen datos con una estructura especial puedan implementar su propio algoritmo. Por ejemplo, PostGis puede implementar algoritmos especificos para comprimir sus datos. O un modulo de audio comprima sin perdida aplicando un algoritmo especifico para audio. Sobre el problema de implementacion, se puede pasar a pglz datos ya comprimidos con otro compresor, configurando pglz sin compresion o con la peor compresion posible para que se rinda al procesar los 100 primeros bytes. Esto es similar a insertar en la bd datos precomprimidos como imagenes o documentos pdf. Como tamaño maximo, se perderian los bits que marcan los metadatos del actual algoritmo, ya que la informacion de si esta comprimido o no y con que algoritmo estaria dentro del stream de datos comprimidos, pero perder unos bits en 8KB no es mucho. Como dice el RFC1925, hay que añadir otro nivel de indireccion. Un saludo --- --- Eduardo Morras <emorr...@yahoo.es> - Enviado a la lista de correo pgsql-es-ayuda (pgsql-es-ayuda@postgresql.org) Para cambiar tu suscripción: http://www.postgresql.org/mailpref/pgsql-es-ayuda
