LINUX.ORG.RU

SELECT * FROM ID=x

 


0

1

тупой вопрос:

положим мы имеем таблицу в которой ID это PRIMARY KEY, и в таблице миллиард записей. мы знаем конкретный идентификатор из этого миллиарда и хотим его выбрать. в случае с типом bigint (64 бит) на моих тестах выборка конкретного ID как и можно ожидать мгновенная (доли миллисекунд).

теперь положим что я использую не bigint а bytea и храню там положим sha512 (512 бит), сохранится ли скорость выборки конкретного идентификатора? не деградирует ли индекс в таком извращенном случае?

★★★★

Последнее исправление: quest (всего исправлений: 1)

Работать будет немного медленней, т.к. индекс будет больше, в память будет помещаться хуже, в общем случае надо будет делать больше чтений с диска. Асимптотическая сложность будет такая же — O(lnN).

Legioner ★★★★★
()

В среднем будет несколько помедленее. Хотя, если выборка у тебя разовая, то на ее скорость будет больше влиять окружение, чем тип данных.

Кстати, у тебя индекс использует btree или hash?

grondek
()
Последнее исправление: grondek (всего исправлений: 1)

Можно еще сделать hash индекс, вместо btree.

bj
()
Ответ на: комментарий от grondek

Btree потому что про hash в доке написано что он в wal логи не попадает и если сервер падает - нужно перестраивать индекс.

quest ★★★★
() автор топика
Ответ на: комментарий от quest

Но, по-идее, тебе hash лучше будет именно для производительности, так как у тебя поиск по ==, а не сортировка.

grondek
()
Ответ на: комментарий от Legioner

в теории то вроде да, но не сорвет ли у postgres крышу на практике от таких извращений...

quest ★★★★
() автор топика
Ответ на: комментарий от grondek

выборки такие массовые но они всегда по конкретному ключу, сканирования нет в принципе

quest ★★★★
() автор топика
Ответ на: комментарий от nanonymous

Ну скажем так у меня primary key за последние лет 10 все bigint, думаю как и у 95% народа... впрочем я уже влил миллиард записей в bytea (512 бит), сейчас посторою индекс и проверю

quest ★★★★
() автор топика
Последнее исправление: quest (всего исправлений: 1)
Ответ на: комментарий от quest

А ПК тут вообще не при чем. Он используется для связи таблиц друг с другом. А выборку ускоряет индекс, который может, конечно и совпадать с ПК, но совсем не обязательно. Один из индексов обычно совпадает с ПК, чтоб эта самая связь была эффективной.

А вообще, надо не тыкать пальцем в небо, а смотреть план выполнения.

nanonymous
()
Ответ на: комментарий от nanonymous

PK в смысле уникальный индекс по полю

quest ★★★★
() автор топика
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.