Re: Estrategias de Optimizacion

Yo lo que haria si es posible es dividir discos si es posible (al ser
empotrado no
se como lo manejaras, pero la wal separada vendria bien)

La columna mas importante y grande de la tabla le haria un
alter para set storage external.

Por lo que veo los datos no son individualmente de suma
relevancia, bajaría un nivel de transaccionalidad.

Te aconsejaria hacer un explain del prepare statement cuando
tengas muchos registros (comparandola con un insert comun).

Las consultas como las realizas? estan como prepare statements?

Para hacer un historico, lo que podes hacer es que en el
mismo prepare statemente poner un insert mas para la otra tabla.

El día 11 de febrero de 2009 14:25, Silvio Quadri <silvioq(at)gmail(dot)com> escribió:
> El día 11 de febrero de 2009 9:19, David Rodriguez Sanchez
> <rodriguezsanchez(dot)david(at)gmail(dot)com> escribió:
>> Hola,
>>
>> Necesito ideas sobre posibles estrategias que puedan mejorar los
>> tiempos de respuesta. Estoy trabajando en un sistema empotrado y los
>> tiempos son críticos.
>>
>> - El sistema debe ser capaz de insertar 1000 registros en menos de 1
>> segundo, con una frecuencia de 1 segundo.(Datos de sensores, el tiempo
>> es crítico)
>> - Debe ser capaz de atender a consultas sobre estos datos de forma
>> concurrente a las inserciones.(El tiempo para estas consultas no es
>> crítico)
>>
>> He conseguido que las inserciones se hagan en un promedio de 630
>> milisegundos, de forma estable. Pero el problema es que al realizar
>> consultas de forma concurrente a las inserciones, éstas sufren una
>> latencia y se demoran en más de un segundo.
>>
>> He considerado usar triggers, de modo que, se inserten 1000 registros
>> y un trigger, por cada registro insertado lo inserte en otra tabla de
>> idéntica estructura que actúa de histórico. La idea es que las
>> consultas se realicen en esta segunda tabla histórico, y dejar la
>> tabla original actuando como una tabla cache que solo reciba de forma
>> constante y periódica inserciones. Pero este método crea demasiada
>> latencia, aprox. 4 segundos, por tanto no es viable, a menos que se
>> pueda optimizar.
>>
>> En este punto es donde necesito ayuda, alguna idea que pueda
>> solucionar esta latencia.
>>
>> Os describo el entorno, y lo siento, pero no puedo dar detalles de
>> implementacion. 
>>
>> Cliente:
>> Se ha desarrollado un programa de testeo, codificado en C++ y uso unixODBC
>>
>> Modelo lógico:
>>
>> - Una sola tabla con 62 campos de tipos: long, bool, float, double,
>> bool[], long[] y float[]. (He preferido usar vectores en vez de tablas
>> relacionadas por motivo de rendimiento)
>> - La tabla tiene un indice 'UNIQUE' con dos campos que forman la clave
>> primaria. He leido que es más flexible y potente usar Index Unique que
>> una Primary Key.
>>
>> Sentencias SQL:
>>
>> La secuencia de sentencias que realizo desde C++ es la siguiente:
>>
>> /* //////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////*/
>>
>>
>> //GLOBAL TRANSACTION +++++++++++++++++++++++++++++++++++++++++++
>> START TRANSACTION;
>>
>>
>> //PREPARE STATEMENT
>> PREPARE test (integer,bigint,integer,double precision,double
>> precision,real,double precision,real,
>> "double precision,real,integer,double precision,double
>> precision,boolean,double precision,boolean,double precision[],
>> "real[],boolean[],integer,integer[],integer[] ,integer,integer,integer,
>> "integer,integer,integer,integer,integer,integer,integer,boolean,boolean,
>> "boolean,boolean,boolean,boolean,boolean,integer[],boolean,boolean,boolean,
>> "boolean,boolean,boolean,boolean,boolean,boolean,integer,boolean,integer,integer,integer,
>> "integer,integer,integer,integer,boolean,integer,boolean,integer[]) AS
>>
>> INSERT INTO 'TABLA' VALUES
>> ($1,$2,$3,$4,$5,$6,$7,$8,$9,$10,$11,$12,$13,$14,$15,
>> "$16,$17,$18,$19,$20,$21,$22,$23,$24,$25,$26,$27,$28,$29,$30,$31,$32,$33,$34,$35,$36,$37,
>> "$38,$39,$40,$41,$42,$43,$44,$45,$46,$47,$48,$49,$50,$51,$52,$53,$54,$55,$56,$57,$58,$59,$60,$61,$62);
>>
>>
>>
>> BUCLE ( 125 VECES)
>> {
>>
>> BUCLE( 8 VECES)
>> {
>> SQL += "EXECUTE test('….');// Los datos que previamente se han
>> generado con el programa de testeo
>> }
>> Exe SQL;
>> SI FALLO
>> {
>> ROOLBACK;
>> }
>>
>> //Sumamos el tiempo parcial empleado
>> }
>>
>> //DEALLOCATE PREPARE
>> DEALLOCATE test;
>>
>>
>> //COMMIT GLOBAL TRANSACTION
>> ++++++++++++++++++++++++++++++++++++++++++++++++++++++
>> COMMIT;
>>
>> /* //////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////*/
>
>
> ¿Probaste en mandar las 1000 inserciones como un solo comando SQL,
> separando los inserts por ; ?
>
>
> --
> Silvio Quadri
> --
> TIP 10: no uses HTML en tu pregunta, seguro que quien responda no podrá leerlo
>

--
Emanuel Calvo Franco
Sumate al ARPUG !
(www.postgres-arg.org -
www.arpug.com.ar)
ArPUG / AOSUG Member
Postgresql Support & Admin