По воводу OIDS www.postgresql.org/docs/9.1/static/sql-createtable.html
Tip: The use of OIDS=FALSE is not recommended for tables with no primary key, since without either an OID or a unique data key, it is difficult to identify specific rows.
Теперь я не понял, т.е пробиваетя? Вы втавляете данные в таблицу, колонка remote_id содержит ограничение, что индекс должен быть уникальным, индекс не составной, то значение индекса няпрямую зависит от встявляемого значения.
покажите \d таблицы с реальными данными, ваши данные
insert into test(remote_id, title, local_id) select rand(1000), 'Название', i from generate_series(1,100000) as i;
ERROR: duplicate key value violates unique constraint "unique_remote_id"
DETAIL: Key (remote_id)=(78) already exists.
Да, и на сколько помню отключать идентификатор объекта не рекомндуется без превичных ключей.
@xmdy даже если и не будете использовать нормализацию, в любом случае запрос и агрегированые теги сохраните в кеш, след раз просто возмете эти данные их кеша :)
@sim3x т.е "по человечески"? @xmdy даже уже и не помню как такое вылыло :)
да в вашем случае наверно правильней использовать поле tags как нормализованную таблицу для M2M, т.е только tag_id.
По поводу кеширования, не совсем понял что вы кешируете в redis`е.
Заносите в редисе запрос и его конечный результат, т.е если вы ищете товары с param-1 то это tag_ids и будет ваши результатом, следующий раз вам не придется делать выборку по все базе. Глубже наверно нет делать смыла, тк как это будет пересечение двух множеств param1[tag_ids] x param2[tag_ids].
Блин комент удалил :)
В в каком классе используется переменная? Посмотрите на метод eval и как используется биндинг для этого метода. Подсказка: def a; var = 1; p "#{var}"; end И как связать eval(..., bind) и class_eval :)
Что-то не увидел с чем связан внешний ключь, ну да ладно, вообще да, долго индексирует, попробуйте заоптимизировать мускул. Вообще для внешнего ключа индекс обычно делают, но почему разработчики его не сделали сразу, это вопрос.
По летературе, ни чего не могу посоветовать, т.к сам в основном читаю все что попадается полезное в интеренет, могу дать только общие рекомендации, - ставть индексы на поля, по которым происходит поиск или сортировка, исключить использование ненужных индексов, проверить нужность не нужноть с помощью EXPLAIN ANALYZE.
Т.е стороннее решение, глянул как они обошли ограничение thin - написали свою обвязку для EventMachine поместив ее в rack space и свой класс для отпрвки сообщений. :)
В ветке streaming не создает новый процесс для нового подключения пока не закончит работу текущий, т.е из примера "3.times do |a|" пока не завершит работу, к сереверу не подключится, по крайне мере, прошлой осенью не работало.
Tip: The use of OIDS=FALSE is not recommended for tables with no primary key, since without either an OID or a unique data key, it is difficult to identify specific rows.