WellWisher: что-то я туплю, видимо конец недели ) не будет он составной индекс для сортировки использовать, для: "больше", "меньше", "диапазонов"... будет, для сортировки нет. После "отсечения" по первому условию от второй части индекса какие-то куски, сортировка по всему индексу + слияние будет медленнее чем сортировка полученных результатов, как-то так
в общем заюзать индекс для такой сортировки вряд ли, ускорить выборку можно, хотя при отдаче на клиент 25/250к результатов не факт время сортировки на сервере будет критично
igruschkafox: есть одно "но" у постгеса нет кластерных индексов, он может 1 раз упорядочить данные с помощью CLUSTER table index, если что-то потом меняется, то оно опять же фрагментируется
lelvisl: потому, что любой http запрос это заголовки + тело запроса, params.Encode() делает корректным тело POST запроса, заголовок content-type application/x-www-form-urlencoded говорит что это POST с параметрами, дальше "принимающая" сторона это все понимает и парсит body на предмет параметров в нем
Dark_Dante: храните данные там же где и ваш интернет-магазин, зачем куда-то еще ходить, просто иногда "синкайте" данные. Данных (помимо фоточек) не много, так что вряд ли вам нужно что-то покупать
Dark_Dante: нисколько не займет, у вас же не OLAP, считать вы ничего не будете, если не совсем криво написан сам "интернет-магазин", или что там у вас за данными в БД ходит, то вам до всех этих "зеонов" и "ссд" фиолетово, сходите в "эльдорадо" и купите что подешевле ;)
Иван Лубинский: вашу проблему это точно не решит ) nginx "сверху" поставьте, путь "интернет" смотрит на него (вешаете его на какой-нибудь ip вашей машины который виден снаружи), в nginx проксируете запросы на ваше по которое запущенно супервизором
Oleg Shevelev: я об авторе go-database-sql.org, он собственно и не школьник, Baron Schwartz должен знать "всю кухню", поэтому удивительны эти "surprises"
SELECT с вопросиком "по механике" тотже Prepare (пруф https://github.com/go-sql-driver/mysql/blob/master..., т.е. он отсылает на сервер запрос и отдельно данные - это нормальный режим работы с СУБД который легко посмотреть tcpdump'ом например ;) Prepare отличается от него только тем что сервер СУБД будет ожидать поступление n-го количества запросов с данными
Пул не освещен в документации Go т.к. его работа это и работа sql-драйвера стороннего вендора, поэтому они о нем ничего написать и не могут, это забота автора драйвера, Go только предлагают использовать общий api database/sql
Александр Василенко: gomobile и разделяемые библиотеки для 1,5 специально для этой цели и делали, поэтому если не сейчас (хотя у автора на хабре все гуд) то в будующем стоит ждать улучшений
Oleg Shevelev: ok, давайте о теории и напильниках. Собственно чтоб разобраться что тут и как нужно понимать "механику" работы между приложением и СУБД. С одной стороны понятно что автор go-database-sql.org всю жизнь писал скрипты на Perl и PHP для облегчения работы DBS, с другой стороны не очень, т.к. во внутренностях тогоже MySql он должен разбираться чуть более чем полностью.
Дак вот: между приложением и СУБД устанавливается соединение, когда мы пишем SELECT * FROM dev_method WHERE name=? мы как бы говорим серверу о своем намерении что-либо сделать, он "проверяет" данный запрос и смотрит что делать дальше; плейсхолдер "?" для MySql говорит о том что для данного запроса будут и данные, поэтому он "выбирает их и вставляет в бд", это может быть 1 набор или n-е количество (prepared), все ок. Иньекция - это изменение того самого нашего "намерения", если данные "вставляются" на стороне нашего ПО, то можно "переписать" запрос на валидный с точки зрения СУБД и дропнуть там все на что прав хватит. Поэтому: данные отдельно/ запрос отдельно - хорошо, вставлять в запрос данные - плохо.
О напильниках:
Опятьже автор жил в мире 1 соединения с бд на всю логику его приложения, которое последовательно что-то там делало, одняко в Го - сюрпрайз, соединение с сервером не закрывается после каждого запроса.
"Просто и на пальцах":
Го пулит соединения с СУЬД, если принудительно соединение не закрывать то оно возвращается в пул.
Сюрпризный момент:
db.Query/Exec etc... выбирают соединение из пула, поэтому:
db.Begin()
db.Exec()
db.Commit()
вполне себе могут быть выполнены в разных соединениях что как бы все поломает, но, как написанно в документации делать так не стоит, а стоит "закрепить" за собой соединение до заврешения обработки пачки бизнес логики
tx:= db.Begin() // открываем транзакцию, объект db в tx закрепляет за собой соединение
tx.Query()/Exec()/etc...
tx.Commit()/Rollback() / закрываем транзакцию и возвращаем соединение в пул
Александр Василенко: смотря какие задачи, где-то Go уже заменил C/C++ etc, где-то он их заменить не сможет. Опятьже что считать системными/железячными штуками, через тотже syscall он вполне себе может железяками поуправлять )