Re: particion pg_xlog

El 12 de octubre de 2014, 22:22, Emanuel Calvo<emanuel(dot)calvo(at)2ndquadrant(dot)com
> escribió:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA512
>
>
>
> El 11/10/14 a las 14:27, Eduardo Arenas C. escibió:
> > Jaime,
> >
> > Esto entrego el pg_xlogfile = "0000000100000C5B000000F3"
> >
> > luego de 30 min "0000000100000C5B000000F3" , ahora está full
> > carga de datos.
> >
> > No es una base muy activa, es un sistema de BI que refresca datos
> > durante la noche (aprox 20GB , aprox 50 Millones de registros) , y
> > el fin de semana hace un refresco completo de aprox 100GB.
>
> En ese caso, creo que deberías cambiar la táctica de configuración.
> Más que nada para poder mejorar los tiempos de inserción sacrificando
> algo de durabilidad. Esto es, si la pérdida de datos en esta instancia
> no representa peligro (es decir, que no la lies). También si los
> tiempos de recuperación son buenos.
>

​¿a que te refieres con eso? como se hace???​

>
> >
> > Durante el día no mas de una decena de personas lo consultas sql
> > directo y tenemos algunos reportes y cubos en pentaho BI que se
> > consulta en el portal web de pentaho.
>
> Ahora que comentas esto, quizás el principal problema es que
> seguramente esa carga de datos masiva nocturna puede estar
> "colisionando"con algún reporte o cron que hace consultas u otro
> trabajo en la base.
>
> En el caso que así fuera, deberías corroborar de que la carga de datos
> esté libre de uso de recursos pr parte de otros procesos.
>
> El separar la pg_Xlog en este particular caso no beneficiaría las
> consultas normales de los reportes :)
>

​Dos cosas, si probablemente hay colisiones, pero no con consultas, mas
bien de cargas simultaneas, como estoy haciendo cargas con Pentaho Data
Integration (ex kettle ETL), y estas se hacen por JDBC, sin un poco lentas
lo que me obliga a tirar varias cosas al mismo tiempo, esto lo hago en
forma nocturna, y como esto termina antes de que empiece la operación no
hay problema, pero estoy pensando en una carga mas eficiencia secuencial
por medio de un COPY o un fdw no se si fdw pueda ser mas rapido que el JDBC
de kettle.

Lo otro, esto está en una virtualización y la unidad de disco del equipo,
finalmente es un LUN de un storage, las particiones son volúmenes lógicos
(VL)... dado que comentas que no sería productivo separar el pg_xlog con
esto de los volúmenes lógicos, imagino que será mucho menos performante :(

>
> - --
> - --
> Emanuel Calvo http://www.2ndQuadrant.com/
> PostgreSQL Development, 24x7 Support, Training & Services
> Bs. As., Argentina (GMT-3)
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG/MacGPG2 v2.0.18 (Darwin)
> Comment: GPGTools - http://gpgtools.org
>
> iQIcBAEBCgAGBQJUOzd+AAoJEIBeI/HMagHmD+gQAKFkQIbbDSqTk8XAtBJBKKxY
> IWDdW4fQaaSd9V8W6SetYdlUJ5wYoDaKId1CKsVTS6Mw8CMiaLNHWdsdxqgcse/3
> UWHSXMktro9erRmYQzwhGMMJrScrfQlhniAuOCJ6ZQ0gY5S5rrOeT6imZZUZFsyM
> TbwYZj194E0yF7IFUHY28/EtgD3h4suCdoZQRwPpf5+moVClc/k5Otrfb5zwVxel
> x95aD74pxbJ1SBGxDEn2EX5gVsixizWZgfDnbzLuwF6/XhklTJDMlpHi0zmi/vc+
> mrtqtC8rjOh6nsLN/TzZkywHrATdGMpTi4WQISHgDK+SJXyKfoqddeUnceMrHEJY
> B3e0FWwJUfXSJsPLYjBLisFOftvIyqSSoDhSK6HJbyp1/e4jwutQxOjdoDkRbO0n
> 6X4wJps7j/McikxdPACFWeeVRGKylm/kDGP9gMaSeknO23djIy9tNWstUC3NvvwM
> z1FTWNnUyX2zfUsIwzUR/ChYiFUz419MXmsntXkntTvY6EnzS8XoUXogqp9ys+VF
> ZXlPO/PWJAHpAFqggoii9yKhCFSq6qt68kAP4mjWTtIMn9W1hKRjD/oY83tJc58A
> tdH1H7SjK5kBKkPdelkNA3D5P795xXeayKfQYZGeTJjPSvlZPX4TNSqm+xZnTfLB
> xPlpCplvxht2cH+hukY2
> =o4zA
> -----END PGP SIGNATURE-----
>

--
Eduardo Arenas C.
Jefe de Unidad de Gestión de Información
Ancora UC
+56 0 9 6629 1618
+56 0 22 944 9098