Если поставить тип PK в pg как varchar - очень

плохо будет?

Медленнее будет.

Нет, не будет плохо

Не будет, ерунда это все

Категорически надеюсь, что рядом со мной никогда не будет работать человек который утверждает, что "интовые ключи работают быстрее текстовых" - это ерунда.

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

а детали этого утверждения (или обратного от него) будут? )

Вполне очевидно, что за деталями к утверждающему надо, не?

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

Вся переписка выше. Отдел ничего не обсуждалось. Покликайие на сообщения и сможете перейти на начало.

Ну это все вещи низшего порядка значимости

Так я потыкал на сообщения, конечно, перед тем как спросить ) но что-то не нашел 😅

а какие высокого порядка значимости?

Поиск по индексу O( l og N), независимо от вида ключа.

Вот выше на одно сообщение

И ещё факт что время чтения записи с диска на три-шесть порядков больше времени любой обработки данных в памяти

если размер одинаковый, то не видно за счет чего будет разника. И число и строка хранятся как байты. если там и там 10 байт ( в oracle number до 10 байт занимает). то почему не будет O(logN)?

Алгоритмически-то да, кто ж будет спорить. Я чет стал думать про хранение и тп 😅

А где ты прочел что не будет? Я такое не писал

может я не так понял, что у вас есть утверждение, что поиска по число и строке как-то имеет разную временную сложность в индексе. если они одинакового размера, то я согласен, что разницы нет

А там ничего умного этот товарищ не писал. Просто делитантские выкладки. И ещё одну чушь про индекс и диск изрёк. Видимо не представляет совершенно что есть буфер движка БД. Есть кэш операционки. В абсолютном кол-ве случаев все данные уже в памяти и на диск с его скоростью апелировать глупо выгораживая безалаберное отношение к типам данных и оптимальности в целом. Именно из-за таких прогромистов размер приложений постоянно увеличивается а требования к цпу растут нелинейно.

твои утверждения тоже немного спорны ;) например, вот это: В абсолютном кол-ве случаев все данные уже в памяти

Читай внимательно. Наоборот будет одинаково

Может просто я работал с оптимально написанными БД вертя{имися на хорошем железе?

Тем не менее все выкладки по производительности СУБД ориентируются на время чтения с диска, а не из памяти