Sly32

Интересно, узнал много интересного, о чем и не задумывался про рыбу) В Польше все просто - в магазинах есть łosoś atlantycki есть łosoś pacyficzny(gorbusza) ну и форель. Первые два - выловлены природе, на упаковке всегда указывается номер рыбхозяйства, которое поставляет и можно узнать место добычи. Форель обычно разведенная в садках.  Лосось пласты или тушка без головы - в районе 60-70 злотых за кг(примерно 1500 ваших рублей). Иногда берем и сами солим, потому что тут не существует в природе слабосоленой - только копченая. А мы на завтрак уважаем буер с рыбкой.

Про эти все кеты-кижучи и прочее даже и не помнил.

И да - на мясных изделиях всегда указан процент мяса. Подозреваю, если не указан - его там и нет) Такого добра тоже хватает.

Как по мне нужно быть совсем слепым, чтобы спутать классику с престижными международными наградами(хоть я и не фанат VW) и вот то убожество с полным отсутствием дизайна. 

Куда катится мир... Уже банального Гольфа не узнают, зато скоро все будут знать чем доньфень лучше ханью )))

Visual Studio
GitHub
Azure App Service
Azure Container Apps
Azure Kubernetes Service
Power Apps

Microsoft Intelligent Data Platform
Microsoft AI
Azure SQL
Azure Synapse Analytics
Power BI

Microsoft 365
Microsoft Teams

И это далеко не все... Очень интересно, чем ты это все заменишь))))

Забрал новую игрушку

Решил на практике проверить разницу в скорости запросов. Использовал постгресс 16 с простой таблицей:

create table news
(
    id      serial
        primary key,
    title   varchar(30)  not null,
    content text         not null,
    slug    varchar(128) not null
);

alter table news
    owner to postgres;

create index idx_id_btree
    on news (id);

create index idx_slug_hash
    on news using hash (slug);

create index ix_news_id
    on news (id);

Добавил туда более 100 тысяч записей, и сделал код, ищущий записи по разным полям, обычный селект-where

@timer
    def get_news_by_id(self, n_id):
        stmt = (
            select(News)
            .where(News.id == n_id))
        with Session() as session:

            print("Get by ID"+"="*120)
            print(stmt)
            result = session.execute(stmt).one()
            print("Result:")
            print(result.News.id, result.News.title)
            
            
    @timer
    def get_news_by_slug(self, slug):
        stmt = (
            select(News)
            .where(News.slug == slug))
        with Session() as session:

            print("Get by slug: "+"="*120)
            print(stmt)
            result = session.execute(stmt).one()
            print("Result:")
            print(result.News.id, result.News.title)
            
            
    @timer
    def get_news_by_title(self, title):
        stmt = (
            select(News)
            .where(News.title == title))
        with Session() as session:

            print("Get by title: "+"="*120)
            print(stmt)
            result = session.execute(stmt).one()
            print("Result:")
            print(result.News.id, result.News.title)

И получил интересные результаты:

Get by ID========================================================================================================================
SELECT news.id, news.title, news.content, news.slug 
FROM news 
WHERE news.id = :id_1
Result:
109536 SdGRBUQoZfQDiUh3zTC0wUUzHicUvM
Execution time: 0.0937650203704834
Get by ID========================================================================================================================
SELECT news.id, news.title, news.content, news.slug 
FROM news 
WHERE news.id = :id_1
Result:
109536 SdGRBUQoZfQDiUh3zTC0wUUzHicUvM
Execution time: 0.006050825119018555
Get by slug: ========================================================================================================================
SELECT news.id, news.title, news.content, news.slug 
FROM news 
WHERE news.slug = :slug_1
Result:
109536 SdGRBUQoZfQDiUh3zTC0wUUzHicUvM
Execution time: 0.007730007171630859
Get by slug: ========================================================================================================================
SELECT news.id, news.title, news.content, news.slug 
FROM news 
WHERE news.slug = :slug_1
Result:
109536 SdGRBUQoZfQDiUh3zTC0wUUzHicUvM
Execution time: 0.005480051040649414
Get by title: ========================================================================================================================
SELECT news.id, news.title, news.content, news.slug 
FROM news 
WHERE news.title = :title_1
Result:
109536 SdGRBUQoZfQDiUh3zTC0wUUzHicUvM
Execution time: 0.015486001968383789
Get by title: ========================================================================================================================
SELECT news.id, news.title, news.content, news.slug 
FROM news 
WHERE news.title = :title_1
Result:
109536 SdGRBUQoZfQDiUh3zTC0wUUzHicUvM
Execution time: 0.012657880783081055

Process finished with exit code 0

результат 3 - по неиндексированному полю title - ожидаемо он на порядок меньше. А вот с айди и слагом интересно. Дело в том что первый запрос по айди, где для индексации используется винарное дерево - сильно просаживается по скорости, второй и последующий - такой же или немного быстрее чем поиск по текстовому полю с индексом в виде хэш
А хэш всегда стабилен по скорости, независимо от количества запросов. 
Кто-то может это обьяснить?

С такими размерами спор вообще не имеет смысла. По  мне однозначно проше сделать строковый индекс, хотя бвы потому что он читабельнее.  Полностью согласен что выхлоп не стоит того

Я говорил про идеальный мир. А при использовании хэша и поиска по точному вхождению поиск по хэшируемому индексу будет быстрее. Потому что временная сложность поиска по бинарному дереву будет  O(log n) а для поиска по хэшу -О(1) для случая с хорошо разреженной тоблицы без коллизий, но даже для случая коллизий это будет  O(1 + k/n), где k - количество элементов в списке коллизий для данного хэша, а n - размер хэш-таблицы.

В плане Постгрес это могут быть и b-tree, HASH, GIST,  но да - это все строковые данные, которые проигрывают по скорости b-tree с числами, конечно, зависит от вида поиска, например это точное совпадение или диапазон или полнотекст. 

так что по факту да - для простого запроса будет, например быстрее получить статью из базы по полю айди чем по текстовому полю(индексу) 

Только вот покажите мне тот идеальный мир, где можно обойтись такими простыми вещами?

А разве индексы в БД это не массив хэшей? Тут избыточность мне кажется не причем...