El 17 de mayo de 2011 10:01, Jaime Casanova <ja...@2ndquadrant.com>escribió:
> 2011/5/17 David Montoya <ereth...@gmail.com> > > > > ¿Es necesário hacer un Vacuum de una tabla que no sufre muchas sentencias > Delete o Update? > > si. aunque la razon mas importante la manejara igual el autovacuum > aunque lo tengas "apagado" para esa tabla, si nunca haces un vacuum > habra fragmentacion en esa tabla... aunque ocurra lentamente. > > > ¿Si se realiza un Vacuum FULL cada poco tiempo, lleva menos tiempo > hacerlo que si se realiza después de mucho tiempo? > > no deberias usa VACUUM FULL, solo vacuum es necesario... y si vacuum > mas frecuente implica menos trabajo > > > Basicamente mi duda viene, ya que "administro" (se le dedica el tiempo > libre) una BD (por encima hay un pgpool) de unos 128GB en > > la cual una de las tablas se lleva prácticamente el 98% del espacio > ocupado (el autovacuum no se ejecuta en esa tabla). > > la cual es probablemente una tabla historica, personalmente yo > pensaria en particionar la tabla. Sí. La tabla se trata de un histórico, gracias por el consejo, voy ha echarle un vistazo a eso. > > CREATE INDEX inidice_tabla_grande_idvariable_fecha > > ON tabla_grande > > USING btree > > (idvariable, fecha); > > realmente necesitas este indice? es igual al PK solo que con las > columnas al reves y postgres puede usar el indice del PK para resolver > cualquier consulta que resuelvas con esta... > > Si no entendí mal la documentación en su día con el BTree se favorecía las consultas dónde la igualdad estaba más a la izquierda en el índice. En este caso algo del estilo idVariable=34 and fecha <=17/05/2011 and fecha >=12/05/2011 (son estas las peticiones que queremos primar en la apliación). Dicho esto lo que esté mal sea el PK. A todo esto... de que version de postgres estamos hablando? La 8.3 > > -- > Jaime Casanova www.2ndQuadrant.com > Professional PostgreSQL: Soporte y capacitación de PostgreSQL >
