Limitações

As limitações a seguir se aplicam às tabelas estrangeiras. Consulte as versões do mecanismo, as classes de instância e as regiões compatíveis em Consulta de dados do Apache Iceberg e Parquet diretamente no Aurora PostgreSQL.

Modificação de dados

• Acesso somente leitura: essas tabelas externas são somente para leitura. As operações INSERT, UPDATE, DELETE, TRUNCATE e COPY FROM em tabelas estrangeiras não são compatíveis. Para modificar os dados, atualize os arquivos de origem no Amazon S3 (para Parquet) ou atualize a tabela Iceberg por meio do AWS Glue ou de outras ferramentas.

• O bloqueio de linhas não tem efeito: é possível incluir as cláusulas de bloqueio FOR UPDATE, FOR NO KEY UPDATE, FOR SHARE e FOR KEY SHARE em uma consulta. A consulta é executada e retorna linhas. Esse é o comportamento padrão do PostgreSQL para wrappers de dados estrangeiros, e não algo específico desse recurso.

Formato de dados e esquema

• Pontos de acesso multirregionais do Amazon S3 não são compatíveis: o local de uma tabela estrangeira pode ser um URI s3://, um ARN do AWS Glue Data Catalog ou um ARN das Tabelas do Amazon S3. Os ARNs e os nomes de host dos pontos de acesso multirregionais do Amazon S3 (MRAPs) não são compatíveis como local de uma tabela estrangeira.

• Limitações de tipos de dados: alguns tipos de dados do PostgreSQL não têm um mapeamento compatível. Os tipos JSONB, SERIAL, de matriz, de rede, de intervalo, geométricos e XML não são compatíveis. Para obter mais informações, consulte Formatos de dados e mapeamento de tipos.

• Limite de comprimento dos nomes de colunas: os nomes de colunas inferidos dos metadados do Parquet ou do Iceberg não podem exceder 63 caracteres (o limite NAMEDATALEN do PostgreSQL).

• Colisões de nomes de colunas que não diferenciam maiúsculas de minúsculas: uma tabela estrangeira não pode conter duas colunas cujos nomes difiram apenas pelo caso da letra ASCII (por exemplo, "Foo" e "foo"). Se os dados subjacentes contiverem essas colunas, renomeie-as nos dados de origem.

• Restrições de ordenação: somente as ordenações C e ICU são compatíveis nas definições de colunas de tabelas estrangeiras. As ordenações libc (como en_US) e as ordenações personalizadas não são compatíveis nas colunas de tabelas externas. É possível usar ordenações libc no nível da expressão nas consultas, mas isso pode reduzir a otimização de envio.

Execução de consultas

• Acesso a dados de uma única região por consulta: não é possível acessar dados de várias regiões da AWS em uma única consulta. Todos os dados do Amazon S3 acessados em uma consulta devem estar na mesma região.

• Colunas do sistema inacessíveis: o Aurora PostgreSQL não é compatível com as colunas do sistema do PostgreSQL (ctid, xmin, xmax, cmin, cmax e tableoid) em tabelas estrangeiras. Referenciar uma dessas colunas retorna o erro [Aurora Analytics] system column is not supported.

Infraestrutura

• O cache não é persistente entre reinicializações: o cache de leitura em disco é limpo quando uma instância de banco de dados é reiniciada ou ocorre um failover. As consultas subsequentes buscam os dados novamente no Amazon S3.

• Considerações sobre o ajuste de escala do Aurora Sem Servidor: nas implantações do Aurora Sem Servidor v2, a execução simultânea de várias consultas de analytics que consomem muitos recursos pode exceder a velocidade com que a instância de banco de dados consegue aumentar a escala verticalmente.