É REALMENTE possível que o pedido não seja garantido para esta tabela derivada redundante específica?

Eu me deparei com essa pergunta em uma conversa no Twitter com Lukas Eder .

Embora o comportamento correto seja aplicar a cláusula ORDER BY na consulta mais externa, porque, aqui, não estamos usando DISTINCT, GROUP BY, JOIN ou qualquer outra cláusula WHERE na consulta mais externa, por que um RDBMS não passaria o dados recebidos como foram classificados pela consulta interna?

SELECT * 
FROM (
    SELECT * FROM table ORDER BY time DESC
) AS t

Ao executar este exemplo no PostgreSQL, pelo menos, você obtém o mesmo Plano de Execução para a consulta interna e para o exemplo da tabela derivada, além do mesmo conjunto de resultados.

Portanto, suponho que o Planejador simplesmente descarte a consulta mais externa porque é redundante ou simplesmente passa pelos resultados da tabela interna.

Alguém acha que isso pode não ser o caso?

A maioria dos bancos de dados é bastante clara sobre o fato de que uma ORDER BYsubconsulta é:

• Não permitido: por exemplo, SQL Server, Sybase SQL Anywhere (a menos que seja complementado com TOPou OFFSET .. FETCH)
• Sem sentido: por exemplo, PostgreSQL, DB2 (novamente, a menos que seja complementado com OFFSET .. FETCHou LIMIT)

Aqui está um exemplo do manual do DB2 LUW (ênfase minha)

Uma cláusula ORDER BY em uma subseleção não afeta a ordem das linhas retornadas por uma consulta. Uma cláusula ORDER BY afeta apenas a ordem das linhas retornadas se for especificada na seleção completa mais externa.

A redação é bastante explícita, assim como no PostgreSQL :

Se a classificação não for escolhida, as linhas serão retornadas em uma ordem não especificada. A ordem real nesse caso dependerá dos tipos de plano de varredura e associação e da ordem no disco, mas não deve ser invocada . Uma ordem de saída específica só pode ser garantida se a etapa de classificação for escolhida explicitamente.

A partir dessa especificação, pode-se concluir que qualquer pedido resultante da ORDER BYcláusula em uma tabela derivada é meramente acidental e pode coincidir com o pedido esperado (o que ocorre na maioria dos bancos de dados em seu exemplo trivial), mas não seria prudente confiar em isto.

Nota lateral no DB2:

Em particular, o DB2 possui um recurso menos conhecido chamadoORDER BY ORDER OF <table-designator> , que pode ser usado da seguinte maneira:

SELECT C1 FROM
   (SELECT C1 FROM T1
      UNION
    SELECT C1 FROM T2
    ORDER BY C1 ) AS UTABLE
ORDER BY ORDER OF UTABLE

Nesse caso em particular, a ordem da tabela derivada pode ser explicitamente reutilizada na classe SELECT mais externa.

Nota lateral no Oracle:

Durante anos, é uma prática do Oracle implementar a OFFSETpaginação usando ROWNUM, que só pode ser calculada razoavelmente após o pedido de uma tabela derivada:

SELECT *
FROM (
  SELECT rownum AS rn, t.* -- ROWNUM here depends on the derived table's ordering
  FROM (
    SELECT * FROM table ORDER BY time DESC
  ) t
) t
WHERE rn BETWEEN 10 AND 20

Pode-se razoavelmente esperar que, pelo menos na presença de ROWNUMuma consulta, as futuras versões do Oracle não quebrem esse comportamento para não quebrar praticamente todo o Oracle SQL herdado, que ainda não migrou para o muito mais desejável e OFFSET .. FETCHsintaxe padrão legível do SQL :

SELECT * FROM table ORDER BY time DESC OFFSET 10 ROWS FETCH NEXT 10 ROWS ONLY

Sim. Sem uma ORDER BYcláusula, a ordem de saída é indefinida e o planejador de consultas está dentro do seu alcance para assumir que você sabe e entende isso.

Ele pode decidir que, como a consulta externa não especifica uma ordem, ela pode descartar a ordem na consulta interna para evitar uma operação de classificação, especialmente se não houver um índice clusterizado ou nenhum índice para dar suporte à ordem. Se não o fizer agora , poderá funcionar em versões futuras.

Nunca confie em comportamento indefinido. Se você precisar de um pedido específico, forneça uma ORDER BYcláusula no local apropriado.

É o mesmo problema de comportamento indefinido - funciona para você, funciona para mim, reformata o HDD em prod;)

Podemos dar um passo atrás e dizer que, em certo sentido, você está certo - não há razão terrena para que um RDBMS sano reorganize as linhas na seleção interna. Mas isso não é garantido - o que significa que, no futuro, pode haver uma razão, e os fornecedores são livres para fazê-lo. Significando que qualquer código que se baseia nesse comportamento está à mercê de uma alteração que um fornecedor poderia fazer e que não teria obrigação de divulgar, pois não é uma alteração de quebra de um API POV.

É REALMENTE possível que o pedido não seja garantido para esta tabela derivada redundante específica?

A resposta para todas as versões existentes do Postgres (que você estava testando) é: Não - para esta consulta específica. A ordem de classificação é garantida.

O pessoal do servidor SQL ficará desconfortável com isso, pois a Microsoft nem permite ORDER BYsubconsultas. No entanto, a ordem de classificação é garantida para essa consulta simples no Postgres. ORDER BYé aplicado na subconsulta e a consulta externa não faz nada que possa alterar a ordem.

O manual até sugere isso no capítulo Funções agregadas :

Como alternativa, fornecer os valores de entrada de uma subconsulta classificada geralmente funcionará.

Observe que isso é verdade apenas enquanto os níveis de consulta externa não adicionam operações que podem alterar a ordem. Portanto, é apenas "garantido" para o caso simples, e isso não é suportado pelo padrão SQL. O Postgres pode reordenar se for oportuno para operações adicionais. Em caso de dúvida, adicione outro ORDER BYao exterior SELECT. (Nesse caso, o interior ORDER BYseria um ruído redundante para esta consulta simples.)