PostgreSQL v7.3.3 is out

> я знаю точно что нельзя поручать mysql -- stream of inserts starves select

Ну этот факт уже сильно оброс бородой. В каком году последний раз тестировал и какую версию?

> Требуемый уровень -- порядка 100+ инсертов/сек (это минимум).

Тоже очень смешной уровень... для mysql. У меня сохранились
результаты тестов, которые я делал на новом сервере полтора
года назад. Железо: athlon1400/512RAM. Вот они:

Testing server 'MySQL 3.23.40 log' at 2001-10-13 9:57:26

Testing the speed of inserting data into 1 table and do some selects on it.
The tests are done with a table that has 100000 rows.

Generating random keys
Creating tables
Inserting 100000 rows in order
Inserting 100000 rows in reverse order
Inserting 100000 rows in random order
Time for insert (300000): 32 wallclock secs ( 7.73 usr 1.90 sys + 0.00 cusr 0.00 csys = 9.63 CPU)

Нетрудно посчитать, что совершалось примерно 9375 инсертов в секунду...

А то, что постгрес + жаба = тормоза форева, это можно наглядно
лицезреть ежедневно на примере этого сайта...

2 anonymous (*) (2003-05-30 13:41:19.844237)
Ja dumaju problema LOR-a v connecte. Hotja mozet i zagruzennost'..

а как он по надежности будет? бухгалтерию ему можно доверить?

Неправильно думаешь. Я сижу на mtu, и traceroute показывает, что до linux.org.ru 6 хопов. А тормоза такие, как если бы их
было 60. Я смотрел www.linuxhacker.ru, www.ratel.ru из той же
сети. Открываются быстро. Интересно было бы увидеть другие
сайты на этой машине, которые используют не жабу, а, например,
php. Ау, green, дай адресок для проверки гипотезы ;)

Проблема не в жабе, а в постгресе. точнее в постгресе + больших и не всегда оптимальных запросах. Как workaround применялся метод ограничения числа java конекшенов до 10ти, чот и видится с наружи как жуткие тормоза при попытке забрать что-то от жабы.

linuxhacker.ru и linux.org.ru живут на одной физической машинке. Всякие ужасы по загрузке cpu, памяти и тп видно на http://linuxhacker.ru/stats

(забавный факт, select * from somebase where someint=X order by otherint на одной из табличек выполняется в 10 (десять) раз дольше чем select * into temporary table TEMPTABLE where someint=X ; select * from TEMPTABLE order by otherint; По крайней мере если верить explain и explain analyze

В этом ключе я сегодня походил и пооптимизировал слегка запросы. Тем не менее основным cpu-hog'ом по прежнему является postgres, java даже не показывается из-за горизонта)

2vada: Некоторые проблемы, которые ты описал тут решены в 7.3.3.

А вообще IMHO PostgreSQL замечательная СУБД, этакий miniOracle, что бы там не говорил ifconfig, я охотнее поверю Bruce Mommajan, который разрабатывает PostgreSQL, пишет про него книжки и работал в отделе по внедрению Oracle. Так вот он писал, что был и есть стабильный процент клиентов, которые в целях экономии с радостью для себя открывают PostgreSQL и покупают его с поддержкой и все у них работает ни чуть не хуже Oracle, думаю понятно, что затратная часть ниже, чем у Oracle - значит для этих клиентов PostgreSQL эффективнее Oracle.

А вообще IMHO опять таки я бы не рекомендовал production server переводить на новый PostgreSQL со старого, если у нового в третья цифра в номере версии ниже 3. То есть этот 7.3.3 - в самый раз. :)

BTW Участвовал в разработке OnLine E-Commerce системы на PostgreSQL, работает быстро и надежно, программисты сначала жаловались (не возвращал PostgreSQL таблицы, не поддерживался Sybase DataBase Architect), а теперь очень рады, и двигают это решение по всей России, и дешевизна и простота, вместе с надежностью и безопасностью PostgreSQL дает им преимущество перед рядом заказчиков.

P.S. Звучит как реклама :))) знаю, но это те выводы, которые я сделал, довольно таки хорошо, даже глубоко освоив PostgreSQL с версий 6.x до текущих (исходники правил, менял системные таблицы в ряде экстрим случаев).

Делал сравнения СУБД по скорости и цене/качество применительно к тому проекту. Для себя выяснил, а потом и подтвердил, что Interbase, например, (проверил недавно еще раз) - медленная, со слаборазвитым синтаксисом SQL СУБД, она сразу отвалилась, и даже сейчас я не вижу проектов, где она может конкурировать с PostgreSQL на платформе Linux. Informix, Oracle, Sybase работали примерно одинаково для нас. Простота установки и управления (на начальной стадии проекта) у Oracle была сложнее, далее Sybase, Informix был проще среди этих 3-х коммерческих, PostgreSQL - очень просто, в традициях UNIX, правда, если будете тюнить его - придется доки читать, и технические тоже (понимать что делает СУБД на уровне ОС), и править конфиги. Тюнится, кстати очень хорошо, надо его только понять :)

Некоторые, возможно полезные, заметки:
1. Для PostgreSQL в многоклиентской работе лучше 2 процессора по 500МГц, чем один на 1000МГц.
2. Документации по PostgreSQL - для меня, как администратора сервера и администратора безопасности было выше крыши.
3. Почти все СУБД показали 30% прирост производительности на том же железе (с настройками по умолчанию) в Linux перед Windows NT 4.0 и Windows 2000 (на этой меньше тестировалось).
4. Проекты на gborg.postgresql.org в большинстве своем не пригодны для production use в настоящий момент (во всяком случае, те, что мы смотрели).
5. Будут вопросы - пишите, я постараюсь ответить, если смогу. Только не по запросам SQL :)))

> я охотнее поверю Bruce Mommajan, который разрабатывает PostgreSQL, пишет про него книжки

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

На этом сайте есть Korwin - он очень хорошо разбирается в PostgreSQL и XML.

> выполняется в 10 (десять) раз дольше чем select * into temporary table

green, не &бись, сноси постгрес, поставь mysql и радуйся жизни.
А любителей маленького, но сраного оракла посылай всех на ^уй
писать книжки про то, как он классно на бумаге работает.

2anonymous (*) (2003-05-31 02:23:41.785762): пишу чтобы другие, посещающие этот сайт чего не подумали, загляни в исходниках PostgreSQL:
cat ./postgresql-7.3.2/doc/TODO.detail/*|grep Bruce
так интереса ради ... ничего не хочу плохого сказать о green, но какие такие сложные запросы не позволяют делать к СУБД более 10 connections? (если я правильно понял). Выборка чего идет?

Чтобы PostgreSQL работал быстро с таблицами, как те же MySQL попробуйте использовать hash индекс, "может быть поможет" (C) Звери. :)
А ругательства и публичные выступления, это далеко не первый признак большого ума.

Explain не всегда показывает результаты соответствующие реальной работе СУБД (точнее на них не всегда ожно ориентироваться при оптимизации по скорости выполнения запросов), это всего лишь помощник для администратора СУБД по оптимизации запросов и СУБД. Мы сталкивались с такой ситуацией не раз, но разобрались быстро, explain - выдает теорию, оценку определенных показателей, которые не всегда напрямую влияют на скорость выполнения конкретного запроса... И еще, чтобы не было флейма и пр. MySQL отлично подходит для решения многих задач, но у каждого своя ниша, правильно тут не раз писали, что средство надо выбирать под задачу. Раз выбрали PostgreSQL под этот сайт - возможно MySQL "не тянул" запросы, которые использовались программистами сайта. NO FLAME. MAKE LOVE - NO WAR. :))) относитесь ко всему с определенной долей иронии.

Так глубоко в чужом коде я копаться не хочу. Да и неуверен я что заменой на mysql проблема решится. Скорее вылезут грабли с другой стороны. Еще вопрос - потянет ли mysql те же самые запросы сложные запросы ;)

Об'ясняю: конечно никаких проблем делать больше 10ти конекшенов нет, но пи среднем времен ивыполнения запросов около двух секунд, и большом числе клиентов, мы очень быстро оказываемся в ситуации когда сначала у нас 10 одновременных запросов и каждый уже выполняется 20+ секунд реального времени (ну процессор то один). Затем 20 процессов... (потому что новые клиенты то коннектятся и тоже хотят что-то делать...) и так до тех пор пока либо память кончится либо мы упираемся в лимит конекшенов к базе.

Ответ понятен, я надеюсь?

>> Требуемый уровень -- порядка 100+ инсертов/сек (это минимум).

>Тоже очень смешной уровень... для mysql. У меня сохранились
>результаты тестов, которые я делал на новом сервере полтора
>года назад. Железо: athlon1400/512RAM. Вот они:
>Нетрудно посчитать, что совершалось примерно 9375 инсертов в
>секунду...

Неверные условия теста. Да, с инсертами у mysql не было проблемы, была с селектами. Т.е. шла серьёзная конкуренция за одну таблицу, в неё сбрасывались данные и тут же делался select . Просто у инсертов
приоритет по сравнению с селектами, они не давали отработать селектам. select count(*) по этой таблице (400000 записей) занимал
около минуты(время варьировалось сильно). Не надо мне приводить
примеры как быстро у вас будет работать такой запрос, у меня в mysql
на 25млн записей он отрабатывает за секунду, но там нет потока
команд инсерт+селект.

Впрочем, была задача попроще. Есть набор ip address ranges, нужно по
конкретному ip addr выяснить какому набору он принадлежит. структура
таблицы (ip1 int, ip2 int, cntry char(2)). Какие только индексы я не
пробовал (ip1, ip2, (ip1,ip2)) -- без разницы, не добиться скорости,
которой давал оракл на таблице (ip1 number, ip2 number, cntry
char(2)). При том разница в типах данных очень существенна: или
сравнивать два int, или два number (19 bytes каждый).

Мораль: всем этим оптимизаторам запросов фришных sql-серверов ещё
очень далеко до реальных коммерческих. И green'овский пример очень
хорошо это показывает для постгреса.

Explain ANALYZE выполняет команду и показывает реально затраченное время в микросекундах, почему ему нельзя верить?

> с инсертами у mysql не было проблемы, была с селектами.

Может и была когда-то и у кого-то, только не сейчас и не у
меня. У меня бывает периодически шторм инсертов - до 20тыс в
минуту в таблицы, из которых ежесекундно делается select.
В среднем 8 запросов в секунду. Ни разу я не замечал тормозов в этот момент.

> Есть набор ip address ranges, нужно по конкретному ip addr
> выяснить какому набору он принадлежит. структура таблицы (ip1 int, ip2 int, cntry char(2)).

Спешу обрадовать: это вообще _работа_не_для_SQL-сервера_.
Для таких целей используют cdb, gdbm и т.п. Я для этих целей
использую готовый продукт - GeoIP (http://www.maxmind.com/geoip/)

> > с инсертами у mysql не было проблемы, была с селектами.

> Может и была когда-то и у кого-то, только не сейчас и не у
> меня. У меня бывает периодически шторм инсертов - до 20тыс в
> минуту в таблицы, из которых ежесекундно делается select.
> В среднем 8 запросов в секунду. Ни разу я не замечал тормозов в
> этот момент.

К сожалению, у меня сейчас нет возможности проверить именно тот
вариант нагрузки на InnoDB, если появится, попробую ещё раз. А версия mysql на том сервере (dual p3-850, scsi) была что-то типа
3.23.53, не такое уж старьё.

> Спешу обрадовать: это вообще _работа_не_для_SQL-сервера_.

Гм. Я не знаю, вряд ли оракл не является "_SQL-сервером_", но ему
было натурально чихать, что это не его работа. Он просто работал и
быстро. Кстати, поскольку мне пришлось переписать порядка 60
различных запросов с mysql на oracle, то по второму разу проделывать
обратную работу мне жутков влом.

>>почему ему нельзя верить?
Грин, ты же опытный индеец, рассказать разницу между скоростью и производительностью?

Верить размееться можно, анализировать только надо эту инфу.

пусть меня еще раз назовут "неграмотным", посему я, вероятно, и читаю книги. Есть неплохая книга Белсона по Ораклу, там много чего можно подчеркнуть о производительности.
зачастую полный доступ к таблице, приводит к более быстрому выполнению запроса, но вытеснению из SGA блоков других таблиц.

Вкратце, не все так просто %))

Кстати, с Korwin я общаюсь, вероятно скоро на его сайте появитсья и мое мнение о постгрес.

"чтобы я не говорил", я заинтересован в совершенствовании БЕСПЛАТНОГО Инструмента для решения мелких задач. Поэтому все движения постгресса мне глубоко симпатичны. Но это не значит, что нужно закрывать глаза на проблемы.

> Еще вопрос - потянет ли mysql те же самые запросы сложные запросы ;)

Не сомневайся. Потянет на ура. Но сразу советую их несколько переделать. Тогда скорость будет еще выше.

Вот смотри твой запрос: SELECT sections.name as ptitle,
groups.title as gtitle, topics.title, topics.id as msgid,
del_info.reason, comments.postdate FROM sections, groups,
topics, comments, del_info WHERE sections.id=groups.section
AND ...

Для mysql самый скоростной вариант будет с применением left join. Проверял много раз. То есть переделать его так:

SELECT sections.name as ptitle, groups.title as gtitle,
topics.title, topics.id as msgid, del_info.reason,
comments.postdate FROM sections left join groups on
sections.id=groups.section left join topics on
groups.id=topics.groupid left join comments on
comments.topic=topics.id left join del_info и т.д.

Однако мне кажется, что база спроектирована криво. К примеру,
зачем создана таблица del_info? del_info.reason вполне
логично держать в таблице comments. Потом section и groups
так же могли сосуществовать в одной таблице, где можно было
построить отношение parent/child.

Короче, когда я слышу крики "mysql не позволяет нам сделать то-то и то-то", эхо отзывается "кривые руки, кривые руки" ;)

Этот форум будет летать как реактивный самолет на mysql.

> 3.23.53, не такое уж старьё.

Лучше использовать ветку 4.0.x.

> но ему было натурально чихать, что это не его работа.

Естественно! За такие-то деньги еще бы он не работал ;)
Только оптимальное ли это решение? GeoIP будет работать на любой шарманке с i586 процессором и 16Mb RAM.

Ok, сегодня/завтра попробую провести несколько экспериментов и посмотрим что из этого выйдет.

В обоих случаях получается полный доступ. У меня сложилось впечатление что в первом случае оно сортирует всю таблицу, затем отдает результат. Во втором чслучае оно делает выборку результата, а затем сортирует только результаты. Отсюда и разницы в скорости.

По поводу кривизны базы - База не была создана в один момент. Структура со временем менялась (причем базу я не проектировал и то чем я сейчас занимаюсь вообще-то не очень близко к моему основному роду деятельности ;) ) Насчет section/groups - неуверен что они могли бы жить в одной таблице.

2saper: На этом сайте есть Korwin - он очень хорошо разбирается в PostgreSQL и XML.
Приятно услышать такой отзыв от человека который сам лучше меня разбирается с PostgreSQL. Спасибо!

По поводу похож ли PostgreSQL на miniOracle на самом деле сложнее чем кажется. Тут вся соль в том, что требовалось от Oracle.
Мне приходилось переводить несколько проектов с Oracle на PostgreSQL и выигрыш был не только экономический, но и в быстродействии и удобствах обслуживания. В то же время другие проекты нереально перевести не точно на PostgreSQL, а вообще на любую другую БД.

ifConfig профессионал-архитектор БД и я хорошо его понимаю его отношение к PostgreSQL. Для людей не сталкивающимися с тонкостями (non SQL standard extensions) Oracle база данных PostgreSQL будет завичательной заменой.

Давайте жить дружно!(copyright(c) Кот Леопольд).

Теперь про asynth insert/select: это проблема для очень многих БД и PostgreSQL не исключение. Особую важность здесь приобретают знания по блакировкам -- их установки, работы и снятию. А также то, как на физ. уровне с ними работает PostgreSQL. К счастью этот момент достаточно хорошо документирован (стандартная документация), а на их сайте есть множество статей посвященных как тюнингу, так и оптимизации запросов -- RTFM!

А вот из всех ожидаемых PostgreSQL 7.4 вкусностей для меня наиболее сладка поддержка Java. Надеюсь, что реализация будет сделана по более верному пути и не будет использоваться подход Oracle.

О наболевшем: XML. Если необходимо эффективно работать с XML хранимый в postgreSQL, то на текущий момент без XML ApplicationServer не обойтись. Когда PostgreSQL научится поддерживать Java этой проблемы уже не будет, но пока помогают методы:
1) кеширование DOM дерева (равно как и кеширование xpath)
2) Написание C/C++ функций для работы с XML внутри БД и для кеширования исп. временные таблицы.

В качестве решения к каждой записи с XML документом храню время его изменения, а в AS храню DOM. Но такой подход в ряде случаем не удобен, а иногда просто не применим.

green, только не забудь повесить индексы на все ключи, по
которым сшиваются таблицы.

> О наболевшем: XML.

Не надо давать глупые (для данной ситуации) советы. У них и без
XML база еле шевелится. И вообще, XML - это красивый фантик, о
нем бесконечно можно писать толстые умные книжки. Но когда дело
доходит до банальной живой реализации на уровне простейшего, но
хорошо посещаемого форума, то вся мудрость этих книжек
превращается в одну короткую фразу: "Это просто не работает".

Green, уже хорошо заметны изменения в лучшую сторону. Страницы
стали открываться значительно быстрее.

Ой, похоже mysql нам не помошник. Сделал такую же базу в mysql (innodb), наполнил тем же контентом и результат меня просто убил.
mysql> SELECT sections.name as ptitle, groups.title as gtitle, topics.title, topics.id as msgid, del_info.reason, comments.postdate
FROM sections, groups, topics, comments, del_info WHERE sections.id=groups.section AND groups.id=topics.groupid AND comments.topic=topics.id AND del_info.msgid=comments.id AND comments.userid=639 AND del_info.delby!=comments.userid ORDER BY del_info.msgid DESC LIMIT 20;
12 rows in set (41.43 sec)
повторный запрос такой же самый:
12 rows in set (59.26 sec)

При этом на postgres:
database=# explain analyze SELECT sections.name as ptitle, groups.title as gtitle, topics.title, topics.id as msgid, del_info.reason, comments.postdate FROM sections, groups, topics, comments, del_info WHERE sections.id=groups.section AND groups.id=topics.groupid AND comments.topic=topics.id AND del_info.msgid=comments.id AND comments.userid=639 AND del_info.delby!=comments.userid ORDER BY del_info.msgid DESC LIMIT 20;
...
Total runtime: 2056.64 msec
(17 rows)

Хм, еще и результат другой.

О, посмотрел кстати в таблички mysql когда индексы создавал - так это вообще бред! делаешь 1 insert, а в базе появляется 2 абсолютно одинаковых записи. Потом unique index не делается, ясное дело.
Ну его нафиг, по крайней мере postgres хоть работает ;)

(mysql версии 3.23.56 собраный с оптимизацией под p3 из шапошной src.rpm).

Хм. последующий "select count(*) from sections, groups, topics, comments, del_info;" просто зациклил mysqld... (ни одного сискола и 100% cpu usage)

Это просто выходной и нету нагрузки. Вот в понедельник будет видно что к чему.

ага, индексы по id забыл ;) но это все равно не повод зависать ;)

>> О наболевшем: XML.
>Не надо давать глупые (для данной ситуации) советы. У них и без
>XML база еле шевелится. И вообще, XML - это красивый фантик, о
>нем бесконечно можно писать толстые умные книжки. Но когда дело
>доходит до банальной живой реализации на уровне простейшего, но
>хорошо посещаемого форума, то вся мудрость этих книжек
>превращается в одну короткую фразу: "Это просто не работает".

Про производительность обработки XML я и сам в курсе и знаю когда и как его лучше применять.
Есть задачи когда без XML не обойтись. К примеру банковские приложения взаимодействуют между собой на XML. И не только при межбанковских транзакциях, но и внутри организации и даже внутри одного сервиса.

Те решения которые были предложены, безусловно, являются костылями, но других приемлемых вариантов (без внесения изменений в код БД сервера) я не знаю.

XML живее всех живых при хранении статей. Здесь ему нет равных.

<цитата> 12 rows in set (41.43 sec)

...

При этом на postgres:

... Total runtime: 2056.64 msec (17 rows) Хм, еще и результат другой. </цитата>

Сравнивать число строк в query plan и в result set - это конечно впечатляет.. ;-)

по скорости же могу два соображения высказать - 1) innodb в отличии от myisam фвтоматически подстаиваться под ресурсы компьютера не будет. Его надо настраивать ручками. - Вот тут описано как: http://www.innodb.com/ibman.html#InnoDB_start 2) mysql чувствителен к неявным преобразованиям типов в условиях в join. Если посмотеть explain этого запроса, то я думаю можно будет заметно его ускорить для mysql. (подправив схему.)

<цитата> Хм. последующий "select count(*) from sections, groups, topics, comments, del_info;" просто зациклил mysqld... (ни одного сискола и 100% cpu usage) </цитата>

?? Ваш запрос делает full join для 5 таблиц. Это значит, даже если в каждой таблице будет по 1000 записей, то в resultset получится 1 000 000 000 000 000 записей.

интересно, что вы хотели измерить таким запросом?

<цитата>ага, индексы по id забыл ;) но это все равно не повод зависать ;) </цитата>

И что, вы тот тест по select c кучей join делали для mysql без индексов, а для postgres с индексами?

да, с числом строк я прогнал ;)

Зачем для count(*) full join? оно должно было просто перемножить каунты таблиц.

Да, так все и было. Точнее индексы были все кроме индекса по id. После добавления индексов по id все стало похоже на правду. Правда у меня до сих пор нет об'яснения каким образом некоторые инсерты попали в базу по два раза.

> Ой, похоже mysql нам не помошник.

green, извини конечно, но похоже ты полный профан в данном
деле. Лучше тебе заниматься тем, что у тебя хорошо получается
(надеюсь).

> WHERE sections.id=groups.section AND groups.id=topics.groupid AND

Тебе ж сказали, идиота кусок, что нужно делать left join, и про индексы тебя специально предупредили.

> mysql версии 3.23.56 собраный с оптимизацией под p3 из шапошной src.rpm

А вот к этому шапочному дерьму у меня вообще доверия нет.

Короче, пока я добрый, один раз предлагаю свои услуги по
грамотной настройке всего этого добра.

walrus (*) (2003-05-31 16:43:20.931548):

> Сравнивать число строк в query plan и в result set - это конечно впечатляет.. ;-)

Postgres при explain analyze (в отличие от просто explain) прогоняет запрос. Ну да насколько мысклеводы знакомы с другими продуктами, давно известно. ;)

green (*) (2003-05-31 15:36:08.621912)

> database=# explain analyze SELECT sections.name as ptitle, groups.title as gtitle, topics.title, topics.id as msgid, del_info.reason, comments.postdate FROM sections, groups, topics, comments, del_info WHERE sections.id=groups.section AND groups.id=topics.groupid AND comments.topic=topics.id AND del_info.msgid=comments.id AND comments.userid=639 AND del_info.delby!=comments.userid ORDER BY del_info.msgid DESC LIMIT 20;

> Total runtime: 2056.64 msec

чё-то долго работает для всего 5 таблиц... стандартные вопросы:

1) postgresql.conf правили? если установка по умолчанию --- от тормозов никакие индексы не спасут.

2) vacuum analyze регулярно делается?

3) типы полей в запросе какие? Если не integer (int4), то цифирки 639 имело бы смысел в кавычки взять: '639'.

Вообще могу помочь с настройками/оптимизацией запросов. Опыт есть, изрядный причём...

> чё-то долго работает для всего 5 таблиц... стандартные вопросы:

Да потому что дерьмо полнейшее ваш постгрес. На даннной конкретной задаче хоть ты раком встань, а никогда он не сможет
тягаться с mysql. Разница в производительности при грамотной настройке будет минимум 2:1.

anonymous (*) (2003-05-31 19:39:20.271902):

> На даннной конкретной задаче хоть ты раком встань, а никогда он не сможет тягаться с mysql. Разница в производительности при грамотной настройке будет минимум 2:1.

иди-ка ты свой sql грамотно понастраивай; сначала правой рукой, потом левой. только мозоли смотри не натри...

долго. а что делать?

postgresql.conf конечно правили, но что там нужно поменять чтоб именно такие запросы рулили? ;) vacuum analyze раз в сутки. id конечно же integer

Внимательно готов выслушать все советы по настройке базы и оптимизации запросов. (в том плане что с об'яснениями, а не "сделай то-то и будет тебе счастье потому что так завещал великиу Гуру который жил миллион лет назад на далекой планете")

<цитата>Postgres при explain analyze (в отличие от просто explain) прогоняет запрос. Ну да насколько мысклеводы знакомы с другими продуктами, давно известно. ;) </цитата>

Мысклеводы как раз знакомы.. А вот вы похоже не очень. Если вам нравится постгрес, то стыдно не знать, что при explain analyze постгрес прогоняет запрос, но возвращает не результат запроса, а query plan. И соответственно число строк (17 в данном примере) - относится к query plan.

> иди-ка ты свой sql грамотно понастраивай;

Ну а что ты еще можешь вякнуть, кроме тупых огрызаний? Сказать
тебе нечего, дрочуну сраному. Советы как дрочить ты даешь профессионально. Только здесь требуется нечто иное ;)

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

По настройке mysql? нет уж спасибо.
Впрочем если есть какие-то рекомендации с объяснениями - публикуй их и посмотрим.

А заниматься приходится мне, потому что maxcom'у некогда, а под лежачий камень вода сам знаешь что ;)

> Внимательно готов выслушать все советы по настройке базы и оптимизации запросов.

Green, мой совет один: посылай любителей постгрес на три
буковки и ставь mysql. Сам будешь доволен и детям своим
расскажешь, как на ровном месте увеличил производительность
сайта в пять раз. Давай мэйл куда писать, проинструктируем по пунктам.

> По настройке mysql? нет уж спасибо.

А чего так вяло? Ты типа крутой пацан, а mysql ниже твоего
полового достоинства, да? Пальцовка и игры в администраторов
самых крутых sql-серверов дороже реальной работы, качественной и быстрой?