Consulta recursiva em greenplum - greenplum

Eu preciso criar um campo breadcrumb em uma tabela pai / filho em MPP greenplum

A tabela original tem 2 campos: pai, filho Eu preciso extrair uma visão com o breadcrumb

Por exemplo, ter esses registros

1, 2
1, 3
2, 4
4, 5

Eu preciso extrair:

1/2
1/3
1/2/4
1/2/4/5

e assim por diante

O Greenplum é um mecanismo de processamento MPP baseado no postgresql 8.2. Basicamente é um postgres mas, dando a versão, ele não suporta o recurso postgresql "com recursiva" de 8.3.

Além disso, se eu tentar criar uma função para fazer o trabalho eu encontro outras limitações GP

Por exemplo, se eu criar uma função como a seguinte

CREATE OR REPLACE FUNCTION   getBreadCrumb(decimal) RETURNS text AS "DECLARE
itemid ALIAS FOR $1;
itemfullname text;
itemrecord RECORD;
BEGIN
SELECT * INTO itemrecord FROM mytable where father=itemid;
itemfullname := coalesce(itemfullname, """") || itemrecord.father::text;
IF itemrecord.child IS NOT NULL  THEN
itemfullname := itemfullname || ""/"" || getBreadCrumb(itemrecord.child)::text ;
RETURN itemfullname;
ELSE
RETURN itemfullname;
END IF;
END"  LANGUAGE "plpgsql"

e, em seguida, tente selecionar de que eu recebo

ERROR:  function cannot execute on segment because it accesses relation "mytable" (functions.c:152)

o que para mim parece relacionado com a arquitetura "compartilhada nada" do greenplum.

Alguma outra idéia para criar o breadcrumb dando o ambiente que eu tenho?

desde já, obrigado

Respostas:

1 para resposta № 1

Eu tive um problema semelhante ao trabalhar com hierarquias. A única opção para resolvê-lo é escrever uma função pl / pgsql executando no mestre que atualizaria o campo "hierarquia" em um loop como este:

Conteúdos Iniciais:

Node_id | Parent_id | Hierarchy
1       | null      | {1}
2       | 1         | {2}
3       | 1         | {3}
4       | 3         | {4}
5       | 3         | {5}
6       | 5         | {6}

Primeira iteração:

Node_id | Parent_id | Hierarchy
1       | null      | {1}
2       | 1         | {2, 1}
3       | 1         | {3, 1}
4       | 3         | {4, 3}
5       | 3         | {5, 3}
6       | 5         | {6, 5}

Segunda iteração:

Node_id | Parent_id | Hierarchy
1       | null      | {1}
2       | 1         | {2, 1}
3       | 1         | {3, 1}
4       | 3         | {4, 3, 1}
5       | 3         | {5, 3, 1}
6       | 5         | {6, 5, 3}

Última iteração:

Node_id | Parent_id | Hierarchy
1       | null      | {1}
2       | 1         | {2, 1}
3       | 1         | {3, 1}
4       | 3         | {4, 3, 1}
5       | 3         | {5, 3, 1}
6       | 5         | {6, 5, 3, 1}

Uma otimização que você pode fazer para evitar a auto-adesão completa em cada iteração é armazenar o campo "nível" adicional e aumentá-lo para registros atualizados (porque somente os registros são atualizados na iteração). i deve ser considerado para atualização na iteração i+1)

Infelizmente, o GPDB não suporta with recursive e executando consultas no nível do segmento, então esta é a única opção

---