ffflabs's questions

De acordo com os documentos:

CONCORRENTEMENTE Atualize a visualização materializada sem bloquear seleções simultâneas na visualização materializada. (...)

... OUTROS CONTEÚDOS ...

Mesmo com esta opção, apenas um REFRESH de cada vez pode ser executado em qualquer visualização materializada .

Eu tinha uma função que verificava o tempo da última atualização para uma MATERIALIZED VIEW e, se tivessem passado mais de 60 segundos, seria para atualizá-la.

No entanto, o que aconteceria se eu tentasse atualizar uma visão materializada de dois processos separados ao mesmo tempo? eles enfileirariam ou gerariam um erro?

Existe uma maneira de detectar quando uma MATERIALIZED VIEW está sendo atualizada e, portanto, evitar tocá-la?

Atualmente, recorri a preencher um registro de tabela antes de atualizar (definir refreshingcomo true) e, em seguida, defini-lo para falsequando o processo for concluído.

EXECUTE 'INSERT INTO refresh_status (last_update, refreshing) 
         VALUES (clock_timestamp(), true) RETURNING id') INTO refresh_id;
EXECUTE 'REFRESH MATERIALIZED VIEW CONCURRENTLY my_mat_view';
EXECUTE 'UPDATE refresh_status SET refreshing=false WHERE id=$1' USING refresh_id;

Então, sempre que chamo esse procedimento, verifico o mais recente last_updatee seu refreshingvalor. Se refreshingfor true, não tente atualizar a visualização materializada.

EXECUTE 'SELECT 
           extract(epoch FROM now() - (last_update))::integer, 
           refreshing
         FROM refresh_status
         ORDER BY last_update DESC
         LIMIT 1' INTO update_seconds_ago, refreshing;

IF(updated_seconds_ago > 60 AND refreshing = FALSE) THEN
  -- the refresh block above
END IF;

No entanto, não tenho certeza se o sinalizador de atualização está sendo atualizado de forma síncrona (quer dizer, ele realmente espera que a atualização seja realmente concluída)

Essa abordagem é racional ou estou perdendo alguma coisa aqui?

Estou gerenciando uma tabela com vários milhões de registros que estão sendo inseridos em tempo real. Uma parte do meu aplicativo precisa exibir as últimas N linhas inseridas, portanto, no início, apenas consultei:

select id, logdate, content from measurements order by logdate DESC limit 500;

Alguns dias depois, descobri que era mais rápido definir idcomo be (para este exemplo) 10000000000 - extract(epoch from logdate)e usá-lo como PRIMARY KEY, então

select id, date, content from measurements limit 500;

iria naturalmente ordenar por id, produzindo assim os registros mais recentes.

À medida que a tabela crescia, ela se tornava incontrolável, então recorri ao particionamento. Eu fiz exatamente como a documentação diz :

CREATE TABLE measurement_y2007m11 (
CHECK ( logdate >= DATE '2007-11-01' AND logdate < DATE '2007-12-01' )
) INHERITS (measurement);

CREATE TABLE measurement_y2007m12 (
CHECK ( logdate >= DATE '2007-12-01' AND logdate < DATE '2008-01-01' )
) INHERITS (measurement);

CREATE TABLE measurement_y2008m01 (
CHECK ( logdate >= DATE '2008-01-01' AND logdate < DATE '2008-02-01' )
) INHERITS (measurement);

e distribuí as linhas existentes em suas respectivas partições.

O problema é que estou particionando em logdate, mas ao consultar não sei o intervalo de tempo. Quando consulto as últimas 500 linhas, não consigo saber se são da semana passada, do último mês do último trimestre. Portanto, o planejador de consulta sempre verifica todas as partições.

Não acredito que ninguém tenha lidado com esse mesmo problema antes, parece trivial e, no entanto, me deixa intrigado.