Tablas Grandes : 2 Consultas

[seyko]

Buenas amilano,
a ver no hay un numero máximo para el refcursor, pero creo que el problema de manejar un cursor de 2millones de registros es que se carga en memoria y si no cabe en RAM empieza a paginar y de ahi que sea muy muy lento y mientras vayas recorriendo el cursor se hará cada vez más lento.
De ahi la pregunta de si de verdad necesitabas un cursor tan grande.

b. Las Tablas estan indexadas y definidas bajo la forma normal ("Indicevariable"
serial NOT NULL), sin embargo, he observado que en algunas tablas ese
inidice deja de ser consecutivo en alunos registros y se mantiene consecutivo
en otros, incluso en la misma Tabla.

Estás confundiendo conceptos. Esa tabla tiene un campo serial, que te crea una secuencia para insertar por defecto en ese campo. Por tanto, si insertas el 1,2,3 luego borras el 3 y vuelves a insertar usa el 4. Es simplemente una secuencia, a base de borrados y actualizaciones quedan huecos intermedios, es normal y no afecta para nada.
El tema de los indices es otro cantar.

Sobre la vista: CREATE OR REPLACE, esto te borra la vista si ya existe.

in embargo, ello no sucede siempre, sino tambien de manera aleatoria, es decir, en muchos casos hago directamente el SELECT a la función que genera la vista, y tambien se queda en un LOOP para generarla, aun cuando la función que genera tal vista no utiliza elementos generadores de loop (FOR, WHILE, por ejemplo), es decir, la vista en unos casos se genera y en otros no.

A que te refieres con que se queda en un LOOP????

Los datos almacenados en el refcursor, son tomados de muchas funciones que en la mayoría de los casos devuelven, a su vez, un SETOF. Dicho de otro modo, la función que genera el refcursor, llama a muchas funciones que devuelven un SETOF y lo convierte en refcursor.
Entonces el refcursor se utiliza para evitar crear un tipo de dato diferentes, para los resultados de cada función llamada por el refcursor. Los datos a los que se referencia con el refcursor, son enviados a una interfase WEB, que a través de una conexion con BD, llama a una unica función que genera los datos a visualizar en la interfase, por lo que de otro modo, tendría que hacerse la llamada a cientos de funciones diferentes, caso éste, en que igualmente deberian crearse cientos de tipos de datos diferentes.

Uff mandas 2 millones de registros a una interfaze web?????
O buscas la manera de reducir drasticamente el número de registros del cursor o tendrás que buscar otra forma de unir el resultado de las funciones.
Una tabla temporal, vistas, ....

Mira yo he probado esto:

Código:

CREATE OR REPLACE FUNCTION millones() RETURNS boolean AS
$BODY$
DECLARE	
	registro record;
BEGIN
	
	EXECUTE 'create table millones(id serial primary key, valor integer)';
	insert into millones (valor) select n from generate_series(1,2000000) n;
	
	FOR registro IN select * from millones 
	LOOP
		RAISE NOTICE '%', registro.valor;
	END LOOP;

	return true;
EXCEPTION WHEN OTHERS THEN
	RAISE NOTICE 'ERROR: % --> %', SQLSTATE, SQLERRM;
	return false;
END;
$BODY$ LANGUAGE 'plpgsql';

Y tarda un rato, pero claro son solo 2 campos por registro.


Un saludo, a la espera