Надо данные смотреть

'256' - три байта, float - 8

А, text

один столбец text, говорю же) по идее один-в-один должно быть, ну ладно, с небольшим оверхедом

я даже PK убрал на время инсерта

А какой utf у постгреса внутри?

Тоаст, нет?

аэыыы, прекрасный вопрос. внутри это где, как можно посмотреть? когда я делал createdb с сишной локалью, он, помню, ругнулся, что шаблон utf8.en_US использует

более задроченный запрос о размере таблицы показывает 8192 toast_bytes

вот этот https://gist.github.com/hatarist/675dc3debf6cf5f825b5c15aed4cbac0

а всё же зависит от среднего размера записи. если там в каждом text лежит по одному символу, так оверхед будет вообще ого-го

аэыыы, прекрасный вопрос. внутри это где, как можно посмотреть? когда я делал createdb с сишной локалью, он, помню, ругнулся, что шаблон utf8.en_US использует

и попросил сделать с template0

ненене, там в среднем как раз 20-50 символов

оверхед на каджую запись — 28 байт

что в общем уже близко к наблюдаемому

опа, а вот и причина, похоже. 100 млн строк

спасибо большое :) и с этим, понимаю, ничего не сделать?

нет

Только cfs от pgpro

как раз искал подобную штуку, посмотрел на цену, не искал подобную штуку

но я бы не советовал cfs, если планируется интенсивная нагрузка на запись. я почитал дизайн, сравнил с компрессией в innodb. подозреваю, в cfs всё плохо с обновлениями

нене, никакой записи не будет больше, это одноразовая вставка нескольких миллиардов строчек

тогда да

мне приходит в голову совершенно сумасшедшая мысль зафигачить кусками в JSONB, а строками, так скажем, партицировать, ггг

но это как-то слишком упорото, наверное

cstore_fdw глянь

спасиб, что-то не подумал

приложений может быть множество, синхронизировать между приложениями эти данные запарно

А что сложного? Взял nosql БД, например redis, и кешируй там сколько хочешь и как хочешь, и доступ из разных приложений можешь сделать и кластер.

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

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

Да нет же! Не хочется идти по индексу, а получить данные как из хеш таблицы, но при этом не делать это руками :)

ага. а чем индекс отличается от хеш таблицы?

ага. а чем индекс отличается от хеш таблицы?

тем, что он по трем колонкам

в моем случае

я а хочу свести их к одной

таким образом

ага. и чем хеш по трём колонкам отличается от индекса по трём колонкам?

ага. и чем хеш по трём колонкам отличается от индекса по трём колонкам?

хеш будет не по трем колонкам. Грубо говоря бд увидит тот запрос, который уже выполнялся. Например путем вычисления хеш функции по всему запросу

ну это хотелка, а не как оно в реальности :)

как выглядит структура данных, в которой ты хочешь это хранить?

как выглядит структура данных, в которой ты хочешь это хранить?

да пусть даже как хеш таблица. Это может выглядеть так. БД может применить хэш функцию по запросу, и если увидет, что такой уже есть, вернет значение заранее записанное, а не будет лезьт по индексам

по трем колонкам

отлично. где этот хеш лежит? как он аллоцируется? как он деаллоцируется? как он синхронизируется между процессами? как он синхронизируется между репликами?

как в этом хеше считается ключ?

отлично. где этот хеш лежит? как он аллоцируется? как он деаллоцируется? как он синхронизируется между процессами? как он синхронизируется между репликами?

Я без понятия, я спросил есть ли какой то механизм в постгресе для этого :) Но по идее можно это самому запилить

механизм есть, называется "индексы"

Т.е. придумать хеш функцию по переменным в запросе и все

но ты вместо подумать и соотнести говоришь "без понятия", не надо так

вдруг ты можешь адекватно ответить на эти вопросы, а кто-то тут возьмёт и запилит такое

или окажется, что ты придумал shared_buffers

Всем привет, а может кто-то подсказать, можно ли определить в postgres стратегию поведения, в случае, если primary key имеет дефолтное значение, вступающее в коллизию с другим существующим?

duplicate key error будед

потому я порой предпочитаю отказаться от дефолтных автоинкрементных ключей

О'кей. Тогда еще вопрос, если я использую UUID тип для Primary ключа, и хочу генерить его с помощью DEFAULT uuid_generate_v1mc(), у меня может быть коллизия, или же postgre гарантирует их отсутствие?

Просто дико западло переписывать весь SQL из-за возможности коллизий в этом месте :)

там нет гарантий.

ты для начала почитай как оно работает

там вероятность совпадения очень мала + там в уид таймстемп входит

чтобы в 1 момент так влететь....

но гарантий нет

(:

но все юзают. ибо вероятность <censored> мизерная

А способ в рамках СУБД отловить коллизию и перегенерить есть?

https://www.postgresql.org/docs/9.6/static/errcodes-appendix.html

Ну, это то понятно. А внутри никакой возможности отлавливать конфликты нет?

А почему бы не использовать uuid v4?

Если правильно понимаю - v1mc должен быстрее вставляться.

и поиск соответственно быстрее работать.

Мне эти выводы кажутся странными. Возможно что-то недопонимаю.

А почему бы не использовать uuid v4?

в 4ом неймспейса нет :(

А он нужен?

Основная задача, если я правильно понял - исключить возможные "коллизии", не так ли?

ну как. ноды на которых генеришь

это удобно

по ключу можно увидеть с какого конца его сгенерило

или тебе циферка версии повыше душу греет?

Мне душу греет большая степень рандомности, ибо задача ставилась именно такая.

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

Не, я не специалист, просто рассуждения вслух. Возможно я в корне заблуждаюсь.

ну как. идея с отдельным полем тоже здравая.

и поиск соответственно быстрее работать.

А вот это мне вообще никак не понять. Если скорость вставки еще можно как-то объяснить, типа дольше генерится UUID (хотя что-то мне подсказывает, что разница там абсолютно мизерная), то уж скорость поиска никак не объяснима.

А вот это мне вообще никак не понять. Если скорость вставки еще можно как-то объяснить, типа дольше генерится UUID (хотя что-то мне подсказывает, что разница там абсолютно мизерная), то уж скорость поиска никак не объяснима.

Типа данные более упорядочены при больших вставках с одной ноды, эдакая частичная кластеризация

Ага, вот теперь понятно.

Типа данные более упорядочены при больших вставках с одной ноды, эдакая частичная кластеризация

да, вставка будет быстрее.

но вообще uuid это не о больших вставках

но вообще uuid это не о больших вставках

Слишком я привык к UUID, и слишком много кода написал в приложении уже, чтобы рыться там и менять все на сраный Long/Integer ;)

Слишком я привык к UUID, и слишком много кода написал в приложении уже, чтобы рыться там и менять все на сраный Long/Integer ;)

Осторожнее, я помню последнюю битву приверженцев uuid и bigserial в этом чате. Вы играете такими комментариями с огнём)

Осторожнее, я помню последнюю битву приверженцев uuid и bigserial в этом чате. Вы играете такими комментариями с огнём)

Хех, ну, ничего плохого про Integer/Serial не говорю, я только про то, что переписывать на них для меня уже непосильный труд, и придется в незасимости от плюсов/минусов остаться на UUID. А так варианты то каждому под свои цели разные будут.

да, вставка будет быстрее.

Это может показаться странным, но вот я сейчас провел несколько тестов - v1 на вставке проигрывает v4 10 млн записей v1mc вставляет 75-76 секунд, v4 - 56-57 секунд Результат стабилен на нескольких прогонах. Правда эксперимент все же нельзя назвать "чистым", вставка в пустую таблицу вообще без индексов, возможно с индексами результат будет другим. Сейчас и это проверим.

C первичным ключом по uuid v1mc - 107-114-108 секунд v4 - 123-123 -118 секунды Да, при вставке в индекс v4 действительно немного проигрывает. Хотя я бы и не назвал эту разницу существенной. В любом случае, во всех тестах "коллизий" замечено не было

https://telegram.me/telegidka — самые полезные и интересные каналы на просторах Телеграм. Присоединяйся.

Так, кто там искал злобных админов на востоке, которым только выдай банхаммер? Я почти готов карать спамеров