Невозможно обеспечить порядок набора данных, возвращаемых оператором SELECT
, без использования явного предложения ORDER BY
; это верно, даже если данные хранятся в таблице упорядоченным образом. Если вам необходимо упорядочить данные, безопаснее всего определить предложение ORDER BY
.
Запуск SELECT *
против TimescaleDB
Hypertable не будет эффективным. TimescaleDB
хранит данные в виде фрагментов в гипертаблице. Идея состоит в том, что вы привязываете запрос к определенному времени так, чтобы он совпадал с одним конкретным фрагментом, что приводит к оптимальной производительности. Когда вы запускаете запрос, который должен поразить все записи в таблице, теперь он должен просмотреть все данные, содержащиеся во всех чанках, и единственный способ сделать это - через последовательное сканирование.
Это приводит к вашему вопросу о PostgreSQL и получении всех строк. PostgreSQL использует параллельное последовательное сканирование, когда большая часть таблицы будет поражена запросом. Хотя это даст лучшую производительность, чем последовательное сканирование по одному кадру, оно все же не будет таким быстрым, как сканирование по индексу, извлекающее подмножество данных, будет сопоставлено с той же таблицей.
В чем причина необходимости запрашивать все строки в таблице? В силу того, что любой механизм SQL должен был бы просматривать каждую строку хотя бы один раз, чтобы гарантировать, что все строки возвращены, нет никакого способа, которым SELECT *
когда-либо сможет использовать преимущества поиска, связанные с хешированием и индексации.