Re: error : Canceling Query due to user request

Rubén Luna escribió:

> id_solicitud | bigint |
> cod_tipoestado | bigint |
> fecha_cambio | timestamp without time zone |
> rut_receptor | character varying(50) |
> rut_emisor | character varying(50) |
> tiempo | real | default 0

Que son estos RUT? Si son identificadores numericos, por que no usas
"integer"? (Si tienen digitos verificadores, deberias almacenarlos por
separado) Esto puede ayudar muchisimo, porque los indices seran mucho
mas pequen~os (por lo tanto, menor tiempo de insercion y verificacion).

Otro: por que cod_tipoestado es bigint? Acaso tipoestado es bigint
tambien en la tabla tipoestado? Si lo es, por que? No me imagino que
quieras tener mas de cuatro mil millones de tipos de estado, no es asi?

> Restricciones de llave foranea:
> ½fk_estado_reference_tipoesta FOREIGN KEY (cod_tipoestado) REFERENCES
> tipoe
> stado(cod_tipoestado) ON UPDATE RESTRICT ON DELETE RESTRICT
> ½fk_references_solicitud FOREIGN KEY (id_solicitud) REFERENCES
> solicitud(id
> _solicitud) ON UPDATE RESTRICT ON DELETE RESTRICT

La primera te puede estar causando problemas de rendimiento porque en
8.0 los chequeos de FK usan SELECT FOR UPDATE, lo cual serializa el
acceso hasta el fin de la transaccion. Esto es particularmente doloroso
si la tabla tipoestado es pequen~a (digamos, menos de una centena de
registros), o si se usa mayoritariamente un conjunto pequen~o de
registros. Por ej. si todas las solicitudes se crean con estado "NUEVO"
o algo por el estilo.

Un experimento que puedes hacer es eliminar la llave foranea y medir el
tiempo de insercion (nuevamente en una transaccion a la que haces
ROLLBACK). Si disminuye mucho, quiere decir que ese es el problema. Si
no, entonces tienes que seguir buscando.

Si ese es el problema, tienes varias alternativas:
1. usar CHECK en vez de REFERENCES. Esto es bueno solo si los estados
no son muchos.

2. migrar a 8.1, donde las FKs usan SELECT FOR SHARE en vez de FOR
UPDATE. Esto permite hacer los chequeos en paralelo.

3. no se me ocurre otra.

> Lo del insert ficticio nunca lo he probado, voy a intentar ahora.

> aun no comprendo.(hice un vacuum hace poco y me salio por la consola el
> error canceling query due to user request.)quedé mas plop.

"cancelling due to user request" significa que algo externo a Postgres
esta cancelando las consultas. Quizas alguien hizo un programa para
cancelar consultas que bloqueaban a otras consultas? Lo unico que te
puedo decir es que no es implicito de Postgres sino que viene de afuera.

--
Alvaro Herrera http://www.CommandPrompt.com/
PostgreSQL Replication, Consulting, Custom Development, 24x7 support