История изменений
Исправление slovazap, (текущая версия) :
Утверждать такое точно нельзя, как минимум потому что они могут выполняться абсолютно одинаково, например когда вообще нет null значений. Можно было наивно предположить что он выполняется не медленнее, но и это в общем случае неверно.
Джойны можно выполнять кучей разных способов, способы эти планировщик выбирает по прикидкам, и всегда есть случаи когда он ошибётся. Например, из-за наличия большого количества null значений выберет nested loop с fullscan по левой таблице вместо, например, index scan, что теоретически медленнее, но на практике может оказаться быстрее на небольших таблицах, потому что эффективнее последовательно (а может и параллельно) прочитать несколько страниц таблицы, чем рандомно лазить по индексам. Может быть и наоборот, планировщик решит что эффективнее fullscan, потому что записей мало, но на деле в таблице в тысячу раз больше мёртвых строк до которых не успел добраться vacuum.
Причём для двух абсолютно одинаковых запросов идущих друг за другом при отсутствии другой нагрузки может отличаться как поведение планировщика (из-за обновления статистики), так и фактическая производительность (из-за наполнения страничного кэша), причём в итоге в любую сторону.
Исправление slovazap, :
Утверждать такое точно нельзя, как минимум потому что они могут выполняться абсолютно одинаково, например когда вообще нет null значений. Можно было наивно предположить что он выполняется не медленнее, но и это в общем случае неверно.
Джойны можно выполнять кучей разных способов, способы эти планировщик выбирает по прикидкам, и всегда есть случаи когда он ошибётся. Например, из-за наличия большого количества null значений выберет nested loop с fullscan по левой таблице вместо, например, index scan, что теоретически медленнее, но на практике может оказаться быстрее на небольших таблицах, потому что эффективнее последовательно (а может и параллельно) прочитать несколько страниц таблицы, чем рандомно лазить по индексам.
Причём для двух абсолютно одинаковых запросов идущих друг за другом при отсутствии другой нагрузки может отличаться как поведение планировщика (из-за обновления статистики), так и фактическая производительность (из-за наполнения страничного кэша), причём в итоге в любую сторону.
Исправление slovazap, :
Утверждать такое точно нельзя, как минимум потому что они могут выполняться абсолютно одинаково, например когда вообще нет null значений. Можно было наивно предположить что он выполняется не медленнее, но и это обычно неверно.
Джойны можно выполнять кучей разных способов, способы эти планировщик выбирает по прикидкам, и всегда есть случаи когда он ошибётся. Например, из-за наличия большого количества null значений выберет nested loop с fullscan по левой таблице вместо, например, index scan, что теоретически медленнее, но на практике может оказаться быстрее на небольших таблицах, потому что эффективнее последовательно (а может и параллельно) прочитать несколько страниц таблицы, чем рандомно лазить по индексам.
Причём для двух абсолютно одинаковых запросов идущих друг за другом при отсутствии другой нагрузки может отличаться как поведение планировщика (из-за обновления статистики), так и фактическая производительность (из-за наполнения страничного кэша), причём в итоге в любую сторону.
Исходная версия slovazap, :
Утверждать такое точно нельзя, как минимум потому что они могут выполняться абсолютно одинаково, например когда вообще нет null значений. Можно было наивно предположить что он выполняется не медленнее, но и это обычно неверно. Джойны можно выполнять кучей разных способов, способы эти планировщик выбирает по прикидкам, и всегда есть случаи когда он ошибётся. Например, из-за наличия большого количества null значений выберет nested loop с fullscan по левой таблице вместо, например, index scan, что теоретически медленнее, но на практике может оказаться быстрее на небольших таблицах, потому что эффективнее последовательно (а может и параллельно) прочитать несколько страниц таблицы, чем рандомно лазить по индексам.