Tenho uma função que aceita como parâmetro um array como:
CREATE OR REPLACE FUNCTION my_func(some_data custom_datum[]) RETURNS VOID AS $$
BEGIN
create table foo_table as (
select
coalesce(foo_ind, bar_ind, ter_ind) as foobarter,
import_date,
-- do some stuff here
from unnest (some_data) as T
group by grouping sets ((foo_ind, import_date), (bar_ind, import_date), (ter_ind, import_date))
);
END
$$ LANGUAGE plpgsql;
A matriz de entrada é gerada por outra função foo
. Então eu chamo tudo assim:
select my_func(array(select foo()));
onde a função foo
é:
CREATE OR REPLACE FUNCTION foo() RETURNS SETOF custom_datum
O problema é que para uma grande quantidade de dados array(select foo())
retorna:
ERRO: o tamanho do array excede o máximo permitido (1073741823)
O que estou tentando contornar é a falta de possibilidade de passar funções diferentes, pois no momento, o array de entrada é gerado por diferentes funções:
select my_func(array(select foo()));
select my_func(array(select bar()));
select my_func(array(select ter()));
.... etc
Como posso contornar este problema?
O que você
my_func
está fazendo essencialmente é criar umaMATERIALIZED VIEW
-- uma visão materializada é uma cópia em cache de um conjunto de resultados armazenado como uma tabela. Solte a função e use o normalMATERIALIZED VIEW
.Ignore a geração de uma matriz - perda de tempo e espaço e pode até serializar o conjunto de resultados para o disco duas vezes. E, em vez disso, basta usar algo assim:
Agora você pode "atualizar" isso fazendo
REFRESH foo_view;
Você pode limitar a saída de
foo()
:Ou, provavelmente melhor, evite usar arrays completamente (passar o set, não um array feito dele). Para isso, é claro que você terá que reescrever
my_func()
. Pensando nisso, posso imaginar que isso será benéfico do ponto de vista do desempenho também.