Виктор: советуют еще вариант - заменить "IN" на "= ANY". Вроде как во втором варианте POSTGRESQL сам создает временную таблицу со списком из "( )" , джойнит - и т.д.
Виктор: о как....
тогда может быть имеет смысл сперва залить эти "500-1000" значений в БД в темповую табличку (если бы Вы использовали MySQL, я бы еще посоветовал заюзать движок MEMORY ), и уже "там" (в БД) заварить всю кухню? не удивлюсь, если тормоза именно из-за большого размера IN ( ), который БД еще и не может оптимизировать - он указан в явном виде в параметрах запроса.
Виктор: а что у нас в "in ( около 500-1000 значений)" ? там же тоже какой-то SELECT, я предполагаю? сделайте EXPLAIN всего запроса. "Внешний" SELECT ищет по индексу - и ищет не быстро.
4 строки по индексу за 0,6 секунды - это долго. IMHO должно быть раз в 20 быстрее. Совсем древний ноут? винтажный - ламповый?
M0NSTERC4T: IMHO он и не напрямую редактируются - они читаются, далее обрезаются и кладутся в другой каталог. права на /uploads/slides/ и /uploads/slides/small/ какие?
камрад LeEnot дал абсолютно верный совет. Но если все-же хочется странного - загуглите хитровывернутый тип данных ENUM(не уверен, что есть где-то кроме MySQL). Правда для него id групп должно быть фиксировано.
M0NSTERC4T: может косяк в том, что нет каталога large - и процесс не отрабатывает вовсе?
к слову - права 777 на каталог, доступный из инета - не самая хорошая идея.
Василий: может и существуют. Задайте нормальный вопрос в соответствующей ветке - и кто-нибудь обязательно Вам ответит.
На сколько мне известно - в винде встроенной утилиты нет. Собственно говоря - как и линуксе. И там и тут надо поставить что-то дополнительное.
vista1x: Вью+условие и селект, на основе которого сделан вью + условие - суть одно и то-же.
плюсы у вью (если мы говорим о скорости) только в том, что на него а. уже есть план исполнения и б. он, если вы им регулярно пользуетесь, будет закэширован.
объем данных, которые будут перелопачиваться сервером(а как следствие - и скорость), зависит от индексов.
