----- Mensaje original -----
>
>
>
> Esta es la parte del código donde se vuelve extremadamente lento
> dentro del trigger:
>
> SELECT idevent FROM events WHERE ideventtype =
> ANY(et.auto_close_on_event_defined)
> AND status = 0 AND idaccount = NEW.idaccount AND zu = NEW.zu AND
> idevent != NEW.idevent
>
>
> El campo zu antes era tipo texto, lo cambie a bigint, eso mejoro un
> poco pero sigue lento, no se que mas hacer.
> Que campos debo indexar o que podria hacer?
>
>
> /*
> FOR idevent_for_close_on_restore IN SELECT idevent FROM events WHERE
> ideventtype = ANY(et.auto_close_on_event_defined)
> AND status = 0 AND idaccount = NEW.idaccount AND zu = NEW.zu AND
> idevent != NEW.idevent LOOP
>
> INSERT INTO event_comments(
> comment_event, status,
> idevent)
> VALUES ('Event closed for restoring event idevent '||NEW.idevent, 7,
> idevent_for_close_on_restore);
>
> END LOOP;
> */
>
>
> Todo esto pertenece a una aplicacion web de monitoreo de servidores y
> aplicaciones (o algo asi), la he publicado en
> http://openamsdemo-edwinspire.rhcloud.com/oams_contacts.php
>
> Aunque aun no esta la base de datos instalada.
>
>
> Atte:
> Edwin De La Cruz (edwinspire)
> Quito - Ecuador
Una de las reglas que suelen servir para definir la utilidad de un indice, es
que el mismo componga o contenga una deficion parecida al "where" de tu select.
Tal vez un indice por (idaccount, zu)....
Si "status = 0" representa una porcion pequeña de la tabla, entonces crear un
indice parcial seria ventajoso tambien.
Otra chance es que lo lento sean las inserciones en event_comments, y no el
select previo.
Toma ese select, reemplaza los "NEW.campo" por valores reales, y probalo
separado del resto del trigger.
HTH
Gerardo
-
Enviado a la lista de correo pgsql-es-ayuda ([email protected])
Para cambiar tu suscripci�n:
http://www.postgresql.org/mailpref/pgsql-es-ayuda
