нажми explain select ....

и покажи сюда планы

не, план тот же

теория разбитого индекса не сработала

если WHERE auth_user.username тоже использует секскан например, то у тебя проблема с кодировкой

проблем с кодировкой вроде как тоже не должно быть

ну я не знаю как это точно проверить

Вопрос возник, потому что у меня тут есть хранимка, которая изменяет данные и при этом опрашивает внешние ресурсы (партнёров) и ждет от них ответов.

зачем вы так делаете? вы уверены, что не можете заранее подготовить эти данные и прислать в хрантмку?

зачем вы так делаете? вы уверены, что не можете заранее подготовить эти данные и прислать в хрантмку?

а почему бы не писать всё на plpgsql?

а почему бы не писать всё на plpgsql?

опрашивать внешние ресурсы, растягивая тем самым время транзакции? я не против писать на plpgsql. Я даже не против "опроса внешних ресурсов", если он не избежен. Я лишь хотел сказать, что если есть возможность, то лучше все внешние ресурсы опросить до начала транзакции. А хранимка, пока что, является неразрывной частью транзакции.

ну убежать-то можно

ну убежать-то можно

Куда? От кого?

из транзакции, dblink-ом тем же или автономными транзакциями pgpro-шными

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

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

или смотреть прогресс

Mike Chuguniy: Вопрос возник, потому что у меня тут есть хранимка, которая изменяет данные и при этом опрашивает внешние ресурсы (партнёров) и ждет от них ответов.

Я комментировал это сообщение.

Я уже сказал, что действительно бывают ситуации, когда поход во внешние ресурсы изнутри транзакции не избежен (изнутри транзакции не означает только изнутри хранимки, это может быть и на клиенте. Просто изнутри хранимки - это всегда изнутри транзакции). Я просто считаю, что этого следует избегать всеми силами.

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

зачем вы так делаете? вы уверены, что не можете заранее подготовить эти данные и прислать в хрантмку?

Юр, ну тебе-то чего я плохого сделал? :( У меня - да, но мне это хозяйство в наследство досталось - разгребать, почему БД тормозит. Подумаешь секскан на табличку 45+ млн записей. Оно же раз в сутки! Ну вот примерно так. Или файловые операции - с одного сетевого ресурса на другой файлик перекинуть по через хранимку в ПГ - какая мелочь (лог запроса - 4,4 МБ). Я и подумал, что может где-то чего-то пропустил, и тело хранимки более не является цельным куском (транзакцией или частью транзакции)... ЗЫ. А может расскажешь, для зачем походы во внешние ресурсы из хранимки? А то моего опыта категорически недостаточно, чтобы понять, нафига?

телега еще на плаву?

ух ты

рабочий день-то в гос. учреждениях не начался ещё

некому блокировать ?

Завтракают еще, умываются наши "доблестные защитники" от террористов

ктонибудь сравнивал производительность вставки в таблицу с уникальным uuid и просто с интегером?

нашёл сравнения только для мускула и там всё плохо но там нету uuid типа.

телега еще на плаву?

я думаю тут не все из РФ ;)

рабочий день-то в гос. учреждениях не начался ещё

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

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

_ссылка на ролик фаантаазёёёёр_

нашёл сравнения только для мускула и там всё плохо но там нету uuid типа.

думаю, в постгрессе будет примерно так же плохо. и для этого даже не нужен uuid. достаточно просто сравнить вставку по последовательно растущену интеджеру, и по рандомному.

Uuid может быть последовательно растущим. V1 который - он завязан на время - а оно монотонно растёт

Но там высокая вероятность коллизии

Uuid может быть последовательно растущим. V1 который - он завязан на время - а оно монотонно растёт

да, и тогда его вставка будет такой же хорошей, как и вставка растущего интеджера. Конечно, с поправкой на больший размер типа.

Но там высокая вероятность коллизии

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

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

Тут вот в чем проблема - мы генерируем на 1м узле (mac адрес постоянный). Может быть и несколько раз в один интервал времени. Поэтому большая часть uuid константна

Я не понимаю, зачем использовать uuid без специальных случаев. Из специальных случаев хочу отметить - консолидацию бд - например, у пользователей на телефонах ведётся локальная бд, которая периодически сливается в общую базу - там для избежания дублирования нужен uuid. Ну или пример из личного опыта - soap запросы. Где каждый запрос несёт в себе uuid - для его последующей идентификации (учитывая, что клиентов много - идентификацию простым числом делать нельзя)

Я не понимаю, зачем использовать uuid без специальных случаев. Из специальных случаев хочу отметить - консолидацию бд - например, у пользователей на телефонах ведётся локальная бд, которая периодически сливается в общую базу - там для избежания дублирования нужен uuid. Ну или пример из личного опыта - soap запросы. Где каждый запрос несёт в себе uuid - для его последующей идентификации (учитывая, что клиентов много - идентификацию простым числом делать нельзя)

хороший вопрос. Перефразируя классика: "У одного программиста была проблема, и он решил использовать UUID. Теперь у него две проблемы".

Я не понимаю, зачем использовать uuid без специальных случаев. Из специальных случаев хочу отметить - консолидацию бд - например, у пользователей на телефонах ведётся локальная бд, которая периодически сливается в общую базу - там для избежания дублирования нужен uuid. Ну или пример из личного опыта - soap запросы. Где каждый запрос несёт в себе uuid - для его последующей идентификации (учитывая, что клиентов много - идентификацию простым числом делать нельзя)

для безопасности

последовательные ид слишком палевно

Добрый день! Кто-нибудь пользовался утилитой amcheck? Интересует, что делать в случае обнаружения ошибки item order invariant violated for index. Как я понял, элементы строкового индекса хранятся не в том порядке, в котором должны. Правильно ли я понял, что это может аффектить только сортировку?

последовательные ид слишком палевно

Их можно шифровать. В базе использовать последовательные, а наружу отдавать шифрованные. Например, https://ru.m.wikipedia.org/wiki/Speck На самом деле, можно даже финализатор мур-мура с сложениеи с частями ключей на каждом шаге: h = id + k1 h *= m1; h ^= h>>32 h += k2 h *= m2; h ^= h>>32 public = h + k3 Уже будет достаточно, чтобы заебать любого, кто не является признанным экспертом в криптографии. Обращение тоже дешёвая операция: h = public - k3 h ^= h>>32; h *= r2 h -= k2 h ^= h>>32; h *= r1 id = h - k1 Где r1, r2 - обратные множители к m1, m2

для безопасности

Можно id наружу не выставлять )

Можно id наружу не выставлять )

но клиент как то должен индефецировать "обьект" для изменения

Ну тогда не понимаю в чем проблема последовательных значений?

Надеюсь у вас защита от изменения "не тем клиентом" не основана на уникальности id?

Ну тогда не понимаю в чем проблема последовательных значений?

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

Ну бережного, бог бережет. Хэшируйте )

Только поиск по хэш имеет те же проблемы, что и uuid

ну вот по этому и юзаем uuid тем более в java оно из коробки

хотя как по мне это вид паранои но что есть то есть

Только поиск по хэш имеет те же проблемы, что и uuid

Не хэшировать, а шифровать. Тогда можно легко восстановить id.

хотя как по мне это вид паранои но что есть то есть

Номер заказа - информация, которой очень будут рады конкуренты, если он выдаётся последовательно.

Номер заказа - информация, которой очень будут рады конкуренты, если он выдаётся последовательно.

к счастью это не такой кейс

к счастью это не такой кейс

Еще, если где-то не проверяются права на что-то, что кажется не особо значимым, защищает от перебора. В какой-то момент может оказаться, что инфа всё таки что-то значит.

Защищаться должно аутентификацией все же.

Защищаться должно аутентификацией все же.

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

Ребят, чёт уже на мегафоне уже не работает телеграмм. Прощайте те, кто не обойдёт блокировку?

Да не заблокируют ничего

Не ссыте

Москва, Йота уже не не работает

Пишу из Румынии )

Они не смогли заблокировать и бросили кремлевских ботов что бы время выиграть

ERROR: S client not available

Куда бросили?

На базовые станции? ))

вопрос в том что они именно блокируют) судя по всем только домен, точнее его ip

В чаты

нашёл сравнения только для мускула и там всё плохо но там нету uuid типа.

Хорошо сказано %))

только веб сайт заблочили вроде и кажется пытаются ддосить

Москва, Йота уже не не работает

+1

На билайне все ок. А если vpn включить вообще гуд %)

https://reestr.rublacklist.net/ — смотреть тут

https://telegram.veesecurity.com/ Юзайте Просто принять прокси

Йота кстати самая ссыкливая, они цсс гитхаба как то залочили

https://telegram.veesecurity.com/ Юзайте Просто принять прокси

Nordvpn . За бабки правда. Работает гуд. Пока тестирую

Openvpn вродь поддерживает

на андрюше ни один прокси не работает, а на десктопе те же прокси и всё ок. есть у кого такие же проблемы?

Openvpn вродь поддерживает

я использую expressvpn, опенвпн отлично работает но приходится использовать связку с l2tp+ipsec т.к. опенвпн всё ещё не портанули на новый openssl 1.1

я использую expressvpn, опенвпн отлично работает но приходится использовать связку с l2tp+ipsec т.к. опенвпн всё ещё не портанули на новый openssl 1.1

Тут ikev2

Тут ikev2

это кто?

Протокол обмена ключиками

я использую expressvpn, опенвпн отлично работает но приходится использовать связку с l2tp+ipsec т.к. опенвпн всё ещё не портанули на новый openssl 1.1

у меня openvpn работает на openssl 1.1

у меня openvpn работает на openssl 1.1

1.1.0g?

openssl-1.1.0h

у меня openvpn работает на openssl 1.1

И он собран именно с 1.1? а то дистрибутывы часто статически линкуют с нужной версией

openssl-1.1.0h

у меня не собиралась последняя версия openvpn

В винде 1.1 прицеплен по дефолту

И он собран именно с 1.1? а то дистрибутывы часто статически линкуют с нужной версией

да, с 1.1

> бывают ситуации, когда поход во внешние ресурсы изнутри транзакции не избежен @funny_falcon практически в 99,9% -- это признак слабой архитектуры

> бывают ситуации, когда поход во внешние ресурсы изнутри транзакции не избежен @funny_falcon практически в 99,9% -- это признак слабой архитектуры

Да. Но вот тот 0.1% всё таки существует. К тому же, longdist, plproxy тоже не на пустом месте возникли. И различные fdw, в том числе и postgresfdw.

openssl-1.1.0h

https://community.openvpn.net/openvpn/ticket/759 — у меня то же самое что у этого человека, что написал что всё ещё не собирается

Я ручками не собирал, я из дистрибутива поставил

fedora 27

а как вы узнали что openssl 1.1? т.е. он реально с ним слинкован?

посмотрел в —version openvpn