SELECT * FROM ID=x

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

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

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

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

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

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

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

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

Это же СУБД, в чем извращение?

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

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

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

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