Короче ты принят, завтра на 9:00)

Ну ещё расскажи структуру класстерного интекса, некластерного индекса, и таблицы без индекса вообще

индексы очень сильно помогают с where: server не пробегает всю таблицу, а по индексам находит сразу данные. Это можно сказать оглавление таблицы. Кластерный индекс по умолчанию вешается на уникальный столбец и он только один на таблице, некластерных можно хоть сколько повесить. Как определить нужен или нет индекс: берем запрос и смотрим на план выполнения, оптимизатор предложит сам куда повесить индексы, чтобы производительность выросла.

Ненеен СТРУКТУРУ! Какие страницы, что там лежит, как связано...

Там insert, а ты говорил про delet & update

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

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

Совсем нет, но далее он и про DELETE & UPDATE разбирает.

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

Нихера никто не перечитывает. Это для красного словца вставлено.

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

Про оракл -- это кто тебе такое сказал?

Нихера никто не перечитывает. Это для красного словца вставлено.

Я проверял этот пример на Oracle :) все отработало корректно

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

Т.е. ты полагаешь, что после того, как один писатель налетел на лок, и вышел из него, его транзакция заново перезапускается?

Я проверял этот пример на Oracle :) все отработало корректно

Это из цикла "я пощупал слона, он тёплый и круглый!"

Т.е. ты полагаешь, что после того, как один писатель налетел на лок, и вышел из него, его транзакция заново перезапускается?

Я думаю что все кто ожидали окончания лока - продолжают работать со своей версией данных, без учета изменений

Именно так.

Видны только версии записей, коммит которых младше времени начала данной транзакции.

Видны только версии записей, коммит которых младше времени начала данной транзакции.

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

Там уровень один.

не меняется

Это пишушая транзакция.

Если бы там был SELECT а потом UPDATE по данным селекта, то да. Либо если менять на SERIALIZABLE.

А так тут уровень ничего не меняет. Он НОЛЬ. Меньше меньшего. Не может быть другой.

Но поведение по дефолту в двух базах разное и в пг приводит к ошибкам, я об этом

Да одинаковое, оба версионники. Тем более это не чтение, а запись.

Поведение читателей и писателей может отличаться, тут два писателя.

Тут даже блокировочник должен ровно так же работать

Единственно что в блокировочнике будет не так, он не сможет старую версию разблокированной транзакции взять.

Единственно что в блокировочнике будет не так, он не сможет старую версию разблокированной транзакции взять.

Спасибо, вообщем задачка интересная :)

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

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

Понял

это дедлок?

https://pbs.twimg.com/media/ChKxtlFWkAALbkK.jpg

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

Дэдлок, товарищи, дэдлок!

снесём и поднимим из бэкаппа

А вот вопрос. Ни с того ни с сего в mssql один из запросов криво скомпилировался и стал выполняться секунды вместо обычных миллисекунд. А запрос популярный. Выстроилась очередь. Потом локи. Потом пришлось килять процессы. Но они накапливались вновь. Пока не очистили процкэш базы - запрос выполнялся по скомпилированному кривому плану. Впервые такое видел.

Сопсна вопрос - чо это было? И как с этим бороться?

Ad hoc workloads был включён

Сопсна вопрос - чо это было? И как с этим бороться?

А ты можешь это повторить?

Вот когда сможешь повторить тогда и станет понятно что это было:)

Ага повторить тут найти такие штуки бывает сложно ))

Тогда сожнл считать что это редко случающаяся магия. И забить

Тогда сожнл считать что это редко случающаяся магия. И забить

++) ага если начинает повторяться обкладваешь логами все что можно ))

++) ага если начинает повторяться обкладваешь логами все что можно ))

А потом обкладываешь того кто сунул туда руки. И совсем не логами

))

А вот вопрос. Ни с того ни с сего в mssql один из запросов криво скомпилировался и стал выполняться секунды вместо обычных миллисекунд. А запрос популярный. Выстроилась очередь. Потом локи. Потом пришлось килять процессы. Но они накапливались вновь. Пока не очистили процкэш базы - запрос выполнялся по скомпилированному кривому плану. Впервые такое видел.

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

Ну в общем все так и думал. Повтор. Логи. Воспроизведение. Если удастся воспроизвести - в сапорт

Аптайма там, есличо - много. С месяц точно (установка обновлений)

Сопсна вопрос - чо это было? И как с этим бороться?

Типичная штука. Бороться что характерно почти никак нельзя. Можно только прибивать хинтами план хороший к запросу либо как ни странно статистику НЕ updateить на эти таблицы.

join('INNER JOIN', 'image', 'article.id = image.article_id', 'LIMIT = 1')

как тут правилно писат чтобы он взял толко 1 данние?

как тут правилно писат чтобы он взял толко 1 данние?

LIMIT 1

без =

Invalid argument supplied for foreach()

$model = (new \yii\db\Query()) ->select('*') ->from('article') ->join('INNER JOIN', 'image', 'article.id = image.article_id', 'LIMIT = 1') ->join('LEFT JOIN', 'profile', 'article.user_id = profile.user_id') ->all();

Сопсна вопрос - чо это было? И как с этим бороться?

как часто обновляется статистика? ну вот такое бывало у нас и боролись только freeproccache)))

как часто обновляется статистика? ну вот такое бывало у нас и боролись только freeproccache)))

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

как часто обновляется статистика? ну вот такое бывало у нас и боролись только freeproccache)))

Паттерн там такой (у возникновения проблемы) Запрос в кэше, план хороший, работает ОК. Потом кто-то UPDATE-ить статистику. Потом запрос (план) вытесняется из кэша. Потом он запускается на выполнение План строится заново , с новой статистикой. План получается другой и снова кладётся в кэш планов. И пошло-поехало. Я пока писал, понял, что ты имел в виду. Вытеснить плохой план из кэша. ОК, да но надо быть уверенным , что следующий план будет хорошим.

при актуальной статистике шанс больше)

Не факт

Я как раз по то и толкую, что бывает, что новая статистика хуже старой

но она актуальная

а это значит план по идее более подходящий

Ну и что ь

Например на верхней границе гистограммы ....

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

ERROR: S client not available

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

Ты предлагаешь не апдейтить статистику после массовых изменений данных?)

ну одному запросу может и пофиг, но подавляющему большенству других как правило становится плохо)

День добрый, с tarantool кто-нибудь работал?

Ты предлагаешь не апдейтить статистику после массовых изменений данных?)

Да. Вернее, я предлагаю НЕ ВСЕГДА АВТОМАТИЧЕСКИ ТУПО апдейтить статистику.

ну одному запросу может и пофиг, но подавляющему большенству других как правило становится плохо)

Да, я знаю.

Ребят, я новичек в базах, подскажите в чем прокол

ERROR 1045 (28000): Access denied for user 'user'@'localhost' (using password: YES)

ERROR 1045 (28000): Access denied for user 'user'@'localhost' (using password: YES)

неправильная комбинация пароля и логина

error 1045 mysql 28000 access denied for user в гугл и первая ссылка

Без пароля заходит, что самое странное

ну значит пароля не стоит

у этого пользака

Кто нить может помочь с двумя по сути не сложными заданиями по sql? А то у меня мозг взорвался уже))))

Взорвался мозг от не сложных заданий...

Я просто 7 лет не открывал эскуэль

http://www.sql.ru/forum/1295434/kak-vyvesti-polya-iz-rezultata-zaprosa-v-stroku

Тут можно ссылки?

select substring_index(column, '-', 1), concat(substring_index(column, '-', 1), '-', group_concat(substring_index(column, '-', -1) SEPARATOR '-')) from foo group by 1

"На стандартном SQL задача нерешаема. " ну ну...

Спасибо. Сейчас разберусь

Можно я как понимаю склеить было все телефоны через разделитель. С этим проблем нет и запихать в одно значение

склеить то можно, только мух от котлет отделить необходимо

на форум солюшн залей, пусть побомбят

на форум солюшн залей, пусть побомбят

Ну я хотел спросить у тебя) можно ли чтоб бомбануло у них отписаться))

да наздоровье, патент не оформлял

А через pivot как то можно это сделать?

Развернув таблицу

не могу подсказать, с mssql не работал

по моему только там он есть