Ok.. Esa es justamente la opción que nos quedaba por aplicar.... Anoche por otro tema aumenté el work_mem y me quedé pensando si el COPY podría colateralmente verse beneficiado... pero desconozco si usa o no estos espacios?...
De todas formas, después del COPY de esta noche aplicaríamos la asignación de prioridad que indicas.. Gracias Álvaro. Slds. AP. El 20 de abril de 2011 11:09, Alvaro Herrera <alvhe...@alvh.no-ip.org>escribió: > Excerpts from Andrés P.P.'s message of mar abr 19 15:26:44 -0300 2011: > > > Tengo una tabla de 15Mill. de registros... y a las 00:00 hrs. hay una > shell > > que ejecuta en el mismo server de la bd (como root) lo siguiente: > > > > \COPY (SELECT id, fecha FROM data_catalog.tabla) TO '/path/archivo.txt' > > > > Se demora menos de 3 minutos, lo que en términos prácticos a mi juicio > está > > bien, sin embargo, en el mismo horario se produce lentitud en "otros > > procesos" de la plataforma cuyo resultado es que se demoren más de un > cierto > > parámetro de tiempo provocando "alertas de timeout". Estos "otros > procesos" > > se ejecutan durante todo el día, pero en este instante generan esas > > alertas.. > > No existe ningún mecanismo en Postgres para ralentizar un COPY o > similar. Quizás lo que podrías intentar hacer a modo de experimento es > cambiar con ionice la prioridad de I/O que tenga el proceso servidor que > está atendiendo a ese cliente. > > > -- > Álvaro Herrera <alvhe...@alvh.no-ip.org> >
