oriaj's questions

Qual é a diferença entre uma atualização posterior e uma atualização anterior no PostgreSQL? Não consegui entender a diferença entre after updatee before updateporque parece que a função sempre foi executada antes da atualização.

Então fiz o seguinte exemplo:

Fiz uma função que atualiza uma tabela quando o status é typingmas com um atraso de 10 segundos.

CREATE OR REPLACE FUNCTION fai_prueba()
  RETURNS trigger AS
$BODY$
begin
    if new.status = 'Typing' then
        update image set status = 'ToTyping', path = 'Real path' from pg_sleep(5) where id = old.id;
    end if;
    return null;
end;
$BODY$
  LANGUAGE plpgsql VOLATILE
  COST 100;
ALTER FUNCTION fai_prueba()
  OWNER TO postgres;

então eu tenho o seguinte gatilho

create trigger tai 
after update on image 
for each row execute procedure fai_prueba();

mas quando executo um UPDATE a consulta não acaba até acabar o atraso

UPDATE image 
    SET  path='fake path'
       , status= 'Typing' 
WHERE id=5;

>Query returned successfully: 0 rows affected, 10042 ms execution time.

Então, é possível que a consulta de atualização termine antes do gatilho?

Olá tenho um projeto que cria formulários dinamicamente utilizo um modelo como o seguinte:

forms
-----
  id (PK)
  name
  (other fields)

form_fields
-------------
  id (PK)
  form_id (FK to forms.id)
  label (nome to the field)

form_submits (form inserted by someone user)
-------------
  id (PK)
  form_id (FK to forms.id)
  user_id (FK to users.id)

form_submits_fiels 
-------------
  id (PK)
  form_fields_id (FK to form_fields.id)
  form_submit_id (FK to form_submit.id)
  data 

Agora estou tendo sérios problemas com o desempenho no servidor de produção porque a form_elementtabela tem mais de 1.500.000 linhas; o número continua crescendo e a função que retorna todos os registros de um formulário demora mais que 20 segundos, a questão é como otimizar o modelo ou a consulta para levar menos tempo

Tenho algumas ideias mas acho que não resolvem o problema:

• Paginar: se eu pudesse paginar as consultas o desempenho seria muito melhor, mas acho que não é possível porque os dados não estavam em ordem.
• MongoDB: Se usar um modelo não relacional, o desempenho talvez seja melhor, mas não tenho certeza se o mach pode ser melhor com o Mongo e é uma solução tão cara