Re: tamano del blocksize

At 13:58 15/02/2012, Hellmuth Vargas wrote:
>Hola Lista
>
>No claro!! modifique tanto el blocksize como el
>wal-blocksize. (/configure --with-blocksize=16
>--with-wal-blocksize=16) Ademas una vez
>terminada la migración ejecute un vacuum full
>analyze sobre toda la base. Pero el hecho es que
>el desempeño si se ha visto muy
>favorecido: antes, un indice sobre la fact
>table de 17 millones de registros
>demoraba aproximadamente 1:15 min, ahora la
>creación del mismo indice demoro 25 min.. igual las pruebas continuan...

No me referia al uso de ese postgresql en
concreto, la mejora de rendimiento es
considerable al terminar en la tercera parte de
tiempo. Me referia a que si ese postgres lo vas a
usar en un entorno de maestro esclavo como
maestro, el postgresql esclavo debe estar
compilado con estos mismos parametros. Ademas, si
actualizas el postgresql de ese servidor,
acuerdate antes de lanzar la version actualizada
de recompilarla, si no los directorios de datos
se veran comprometidos. Era mas un aviso para que
lo tengas en cuenta antes de que te quedes sin los datos.

Igual si postgres pone el tamaño del bloque como
parte de su configuracion en vez de su
compilacion seria mas sencillo hacer pruebas.
Sqlite por ejemplo te permite cambiar el tamaño
de los bloques/paginas mediante un pragma y haciendo un vacuum.

> .
>
>2012/2/15 Eduardo Morras <<mailto:nec556(at)retena(dot)com>nec556(at)retena(dot)com>
>At 04:46 15/02/2012, Jaime Casanova wrote:
>2012/2/14 Hellmuth Vargas <<mailto:hivs77(at)gmail(dot)com>hivs77(at)gmail(dot)com>:
> >
> > Hoy el tema de desempeno
> > estaba muy penalizado y me dio por revisar el I/O y probar con tamano de
> > bloque mas grande para postgres (16Kb) claro hubo necesidad de compilar y
> > migrar y oh sorpresa: mejoro muchisimo!!! bueno la pregunta es: el tema de
> > los 8Kb es un limite por compatibilidad? seria conveniente considerarlo
> > siempre al realizar una instalacion en servidores relativamente nuevos?
> > muchas gracias lista
> >
>
>Honestamente nunca se me hubiera ocurrido esa solucion... en cuanto a
>tu pregunta, quiza solo es inercia y falta las pruebas de rendimiento
>apropiadas.
>
>sin embargo, aun si fuera asi supongo que solo se recomendaria para
>que el que quiera lo haga. PostgreSQL soporta sistemas muy viejos y
>probablemente en algunos de ellos sea contraproducente hacer eso...
>pero como no tengo datos en los cuales basarme solo estoy asumiendo
>
>
>Ten cuidado al hacer eso. Para empezar si
>quieres usar wal archive o pitr o similares,
>ambos postgres deben tener el mismo tamaño de
>bloque, si no, puede desde indicarte que no
>funciona a corromper los datos en el postgres de
>destino. Si intentas actualizar el postgres
>debes recompilarlo con esta opcion antes de
>lanzarlo, si no puede corromper los datos que tengas.
>
>Por supuesto, el "puede corromper" "puede
>fallar" y demas es un "casi seguro que lo va a hacer".
>
>HTH
>
>-
>Enviado a la lista de correo pgsql-es-ayuda
>(<mailto:pgsql-es-ayuda(at)postgresql(dot)org>pgsql-es-ayuda(at)postgresql(dot)org)
>Para cambiar tu suscripción:
><http://www.postgresql.org/mailpref/pgsql-es-ayuda>http://www.postgresql.org/mailpref/pgsql-es-ayuda
>
>
>
>
>--
>Cordialmente,
>
>Ing. Hellmuth I. Vargas S.
>Esp. Telemática y Negocios por Internet
>Oracle Database 10g Administrator Certified Associate