Aqui envío mas datos -[ RECORD 1 ]-+------------------- relid | 17469 indexrelid | 17531 schemaname | public relname | tabla1 indexrelname | pk_tabla1_codint idx_scan | 62275 idx_tup_read | 64746 idx_tup_fetch | 62275 -[ RECORD 2 ]-+------------------- relid | 17469 indexrelid | 17559 schemaname | public relname | tabla1 indexrelname | uk_tabla1_numero idx_scan | 4151 idx_tup_read | 4484 idx_tup_fetch | 4130 -[ RECORD 3 ]-+------------------- relid | 17469 indexrelid | 17565 schemaname | public relname | tabla1 indexrelname | ix_codintcli idx_scan | 7 idx_tup_read | 1118 idx_tup_fetch | 0 -[ RECORD 4 ]-+------------------- relid | 17469 indexrelid | 17567 schemaname | servicios relname | reclamos indexrelname | ix_codintcon idx_scan | 293 idx_tup_read | 15448 idx_tup_fetch | 14885
-[ RECORD 5 ]-+------------------- relid | 17469 indexrelid | 17569 schemaname | public relname | tabla1 indexrelname | ix_codinteqi idx_scan | 45 idx_tup_read | 1193 idx_tup_fetch | 1053 -[ RECORD 6 ]-+------------------- relid | 17469 indexrelid | 17570 schemaname | public relname | tabla1 indexrelname | ix_dptos idx_scan | 109 idx_tup_read | 1045000 idx_tup_fetch | 4099 -[ RECORD 7 ]-+------------------- relid | 17469 indexrelid | 17571 schemaname | public relname | tabla1 indexrelname | ix_fecha idx_scan | 86 idx_tup_read | 150461 idx_tup_fetch | 50286 -[ RECORD 8 ]-+------------------- relid | 17469 indexrelid | 17573 schemaname | public relname | tabla1 indexrelname | ix_numero idx_scan | 0 idx_tup_read | 0 idx_tup_fetch | 0 El 29 de abril de 2013 15:24, marcelo mendoza <[email protected]>escribió: > Aquí envío algunos datos > Version del PostgreSQL = 8.3.3 en un redhat 4.3 > > -[ RECORD 1 ]--+------------------------------------------------- > relname | tabla1 > relnamespace | 17382 > reltype | 17471 > relowner | 10 > relam | 0 > relfilenode | 85147 > reltablespace | 0 > relpages | 4453 > reltuples | 78269 > reltoastrelid | 85160 > reltoastidxid | 0 > relhasindex | t > relisshared | f > relkind | r > relnatts | 71 > relchecks | 6 > reltriggers | 36 > relukeys | 0 > relfkeys | 0 > relrefs | 0 > relhasoids | f > relhaspkey | t > relhasrules | f > relhassubclass | f > relfrozenxid | 646643 > relacl | {postgres=arwdxt/postgres,dbpublica=arwd/postgres} > reloptions | > > > > > maintenance_work_mem=16mb > > Tamaño de la tabla 35MB > > > > relid | 17469 > schemaname | public > relname | tabla1 > seq_scan | 3769 > seq_tup_read | 303357389 > idx_scan | 66919 > idx_tup_fetch | 759595 > n_tup_ins | 2550 > n_tup_upd | 8083 > n_tup_del | 0 > n_tup_hot_upd | 5619 > n_live_tup | 2548 > n_dead_tup | 2669 > last_vacuum | > last_autovacuum | > last_analyze | > last_autoanalyze | > > > > > > El 29 de abril de 2013 12:21, Marcos Luis Ortiz Valmaseda < > [email protected]> escribió: > > Has visto las estadisticas sobre esa tabla? >> - Cantidad de tuplas muertas >> - Uso de los indices, >> - Tamaño de la tabla y los indices. >> >> ¿Qué versión de PostgreSQL están usando? >> ¿Cuánto tienes dedicado al maintenance_work_mem? >> >> >> El 29 de abril de 2013 11:42, marcelo mendoza<[email protected]> >> escribió: >> >> >> El 29 de abril de 2013 11:42, marcelo mendoza <[email protected] >> > escribió: >> >>> Buenos días grupo, tengo un problema en un sistema de la oficina, cada 3 >>> meses aproximadamente un Update sobre una tabla se vuelve muy lento, cual >>> podría ser la causa y una solución para esto? Solo dandole un reboot al >>> servidor vuelve todo a la normalidad, pero reiniciando el servicio del >>> postgres o reindenxando la tabla no pasa nada, tampoco le hace efecto el >>> vacuum. >>> >>> Saludos. >>> >>> -- >>> Marcelo Mendoza >>> (0983) 383-752 >>> >> >> >> >> -- >> Marcos Ortiz Valmaseda, >> *Data-Driven Product Manager* at PDVSA >> *Blog*: http://dataddict.wordpress.com/ >> *LinkedIn: *http://www.linkedin.com/in/marcosluis2186 >> *Twitter*: @marcosluis2186 <http://twitter.com/marcosluis2186> >> > > > > -- > Marcelo Mendoza > (0983) 383-752 > -- Marcelo Mendoza (0983) 383-752
