Только что проверил на mysql5.7, для удаления таблицы не имеет значения, от какой таблицы frm. Подсунул чужой frm, drop table сделать получилось и затем новый create table уже успешен. Иначе, похоже, без dump/restore не обойтись. stackoverflow.com/a/26981438
Вот что за неуважение? Сами пишете, что не понимаете работу банальнейшего join - и тут же жмёте "пригласить эксперта". Зачем вам срочно эксперт понадобился? Откуда вам заранее знать, что это вопрос уровня эксперт, а не любого мимопроходящего пользователя?
"сейчас окажется, что где-нибудь в прикладном ЯП типа PHP с отключённым отображением ошибок". Ну вот а я о чём? Какой-то PHP и, естественно, с отключенным выводом ошибок. Распечатайте весь fetch_assoc и посмотрите, какой ключ полю присвоен в реальности.
Печально, ICH9 действительно без AHCI был, забыл за давностью лет. У msi один мануал на пачку плат, так что мне просто любопытно - у вас этого пункта в биосе вообще нет?
SSD в режиме эмуляции IDE работать должен. При этом наверняка не будет TRIM и надо намеренно искать SSD с внятно реализованным сборщиком мусора. Но разница в латентности доступа от более медленного интерфейса никуда не девается, упереться на случайных операциях в интерфейс весьма сложно. Разница в производительности с механикой HDD всё равно будет огромна.
Можно для эксперимента взять PCI-E x1 платку контроллера с парой SATA портов и жить на ней.
Я не понял, зачем вам вообще понадобился файлик. Почему вы из своего приложения можете дёрнуть cat (т.е. прав достаточно), но не можете сами читать /dev/ttyUSB0?
Да, из коробки gin не умеет int, есть contrib btree_gin (есть и для gist аналог). Но похоже для пары интов уже имеет значение порядок полей. range по интам умеет.
Впрочем, bitmap index scan может и сам обойти несколько индексов. Не помню, как принято решать вопрос разнообразных комбинаций фильтров.
Почему не сильно дешево?
Взять одну железку на 256гб RAM и проблем с чтения с дисков почти нет.
Например, на ovh от $300 в месяц даже с парой SSD: https://www.ovh.com/us/dedicated-servers/
Скорей всего (я не знаю вашего workload!) вам вполне хватит и 128гб, а то и вообще 64гб под горячие данные. Столько памяти не проблема даже на десктоп поставить.
Можно попробовать один multicolumn gin повесить. Ему, в отличии от btree, порядок полей в индексе пофиг. Постоянно читать всё - всё равно быстро не будет. Чтобы работать адекватно в памяти должны быть горячие данные.
100% промах по буферам, конечно холодную таблицу с диска читать медленно. Даже индекс с диска поднимать пришлось. И work_mem не хватило для bitmap, пришлось скатиться до битмапа по страницам и много recheck'ать по целым страничкам.
Поднимите work_mem для этого запроса. Не скажу на сколько, до пропадания Heap Blocks lossy, т.е. довольно ощутимо от текущего уровня.
Поднимать ли shared_buffers - надо понимать workload базы. Если это холодная табличка и запрос надо редко, можно не трогать. Если она должна быть более горячая - то увеличивать shared_buffers, возможно доставлять память.
> один составной индекс еще решил попробовать тоже btree на поля id и city
id & city? А чем он должен был хотя бы в теории помочь?
Евгений Вольф: всего-то 20 минут? Я уже несколько лет этого понять не могу! Особенно не могу понять, зачем неизвестные мне люди хотят меня добавит и что с ними надо делать.
