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:nec...@retena.com>nec...@retena.com>
At 04:46 15/02/2012, Jaime Casanova wrote:
2012/2/14 Hellmuth Vargas <<mailto:hiv...@gmail.com>hiv...@gmail.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@postgresql.org>pgsql-es-ayuda@postgresql.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
-
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
