good -)

btw никто случайно не видел реализации на SPI функции DNS lookup, которая принимает inet а возращает text? Я вот свою написал, но что-то она изредка в корку сервер валит..

Да! Быстро они поехали! Обновляться не успеваю:-) Все в нем класс - одна проблемма - может не запуститься после экстремальной перезагрузки (и такое бывает :-( ) приходиться где-нить rm <pid file> rm <socket> И что хорошо - похоже флейма не будет:-) Распальцованные ламеры, кричащие пубертатными фальцетами АЦТОЙ, наверное такое не используют:-)

не такая уж и проблема - просто uptime держать надо :) а вот баги с обратной компатабилитой раздражают. вроде такая мелочь - timestamp with/without timezone, ан нет. при перетаскивании дампинга в новейшую версию ошибки сыплются. и прочие подобные насекомые.

да уж попарили они мозги с совместимостью в 7.3... наворотили какого-то "идеологически верного" но совершенно разражающего кастинга... типа была функция с параметром smallint и всю жизнь ее вызывал типа так: foo(1), теперь же надо писать foo(1::smallint), сам он плять догадаться не может...

адним словам - ацтой...

а чего нельзя добавить в rc.local rm /var/lib/psql../*.pid ? чтобы не руками ))

> Вышел очередной релиз PostgreSQL. Одной из хороших, свбодных и надежных систем управления базами данных. В основном исправления ошибок.
одно уточнение: не из хороших, а из лучших :)

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

для anonymous (*) (2003-02-10 05:59:45.735); Из-за того что мускул больше подходит для этой задачи, например он более быстро обрабатывает запросы. Но например для крупных проектов PostgreSQL больше подходит, так как у мускула явно не хватает возможностей.

И это всё сугубое имхо ;)

П. С.: А где посмотреть как переносить строки на этом форуме ? ;)

Гхм, а раньше не переносилось, а лепилось в кучу и всё ;))

А там же где и раньше, смотри выпадающий список над кнопкой "Post/Отправить", там есть такая опция: "User line breaks"

BigBug: Большой проект - это какой? Помнится, Постгрес успешно тормозил при выполнении select из таблицы, объемом 5 000 000 строк... и не надо мне тут флейм разводить про неоптимизированные запросы/таблицы - все было оптимизировано. А знатоки на офсайте говорили: поставь быстрые диски, проводи вакуумизацию раз в полчаса (к слову, при таком объеме она выполнялась в среднем 35 минут). Так что "большой" по понятиям постгресса проект не так уж и велик, если посмотреть на него с точки зрения, например, того же оракла...

> Помнится, Постгрес успешно тормозил при выполнении select из таблицы, объемом 5 000 000 строк...

Точнее пожалуйста. О какой версии идет речь, о каком запросе, какова длительность отработки запроса, число подключений к БД в момент отработки запроса? Действительно интересно, рассматриваю вариант переноса части задач на PostgreSQL.

Для справок: MySQL, стандартный размер одной из таблиц на предварительную обработку - 5 000 000 - 6 000 000 строк. Полет нормальный.

Вопрос ламера: если переходить с FOXPRO 2 - 2.6 (базы небольшие, порядка 200000 записей), то что проще и лучше использовать MySQL или PostgreSQL?

MySQL лучше вообще нигде не использовать, кроме как в www-приладах.

>если переходить с FOXPRO 2 - 2.6 (базы небольшие, порядка 200000 записей),

Выбор - оптимизация по параметрам функциональность/скорость.

ИМХО в данном случае значительных тормозов PostgreSQL не даст, и лучше остановиться на нем.

А под виндой его никто не гонял? Нада продукт под Linux и Вынь.

ЖЖ (perl+MySQL) загибается успешно.

L.

В дополнение: а Rambler (AFAIK) до сих пор работает на PostgreSQL

L.

> проводи вакуумизацию раз в полчаса

Vacuum неэффективен, к сожалению. Пересоздание базы ускорил select-запросы примерно в 10 раз, в то время как vacuum - только на 30% (у меня). Проверяйте сами.

Nail Kashapov.

Да все там намана! Ботва все это. Скорость выборки очень сильно зависит от того, как таблица организована, что в ней ищится, и каким запросом.
Конечно, если поиск идет по текстовому поля (за каким-то фигом длиннолй 250 символов), тады ой! Тут всякий сервак запарится с запросом, а если find by primary key, причем, индекс целое, то...

Действительно, пример неочевиден. Чтоб сделать однозначный вывод, нужно знать все в деталях - что за железо, что за постгрес, что за бд, что за запрос, какие есть индексы. вывод explain нужен. Тогда можно кричать "рулез" или "отстой"...

Ну что ж, подробнее:
Железо:
PII-400, 256M, HDD 8G IDE

База:
PostgeSQL 7.2.1
8 связанных таблиц, самая большая из которых как раз и имела 5000000 строк (и при этом около 60 полей самого разного типа).
индексы были созданы все необходимые и поиск производился по совокупности индексированных полей из нескольких таблиц. Объем выбранных данным - около 1 мегабайта.

Условия:
Тестовое соединение было единственным (!), компьютер ничем, кроме постгресса, в этот момент не занимался. Запрос выполнялся в среднем 90 секунд.

Почему я сказал такое выполнение "тормозами"? Судите сами: на аналогичной машине точно такие же запросы, но уже перенесенные в оракл, работали в 10 раз быстрее (7-9 секунд). При этом оракловый сервер как раз и не был выделен исключительно под эту задачу (постоянно существовало 5-7 соединений к другим базам, размещенным на этом же сервере)

Nail Kashapov: Пересоздание? Информация обновлялась ежедневно примерно в одинаковом объеме, причем, делать это надо было на ходу (не уничтожая уже существующих данных), так что пересоздание исключалось...

vada: Повторюсь, оптимизация структуры проводилась и не один раз. Как раз с учетом explain от самого сервера. Причем над каждым запросом работало несколько человек независимо друг от друга.

Читал, что MySQL поддерживает и koi8-r и cp1251, но при этом в последнем случае букву "я" нельзя использовать. А можно-ли к базам обеих SQL обращаться и Linux- и Windows-клиентам? Какой в случае PostgreSQL и Linux использовать интерфейс пользователя? ( Через веб-браузер бухгалтерские задачи, например, не катит)

///

Народ, не забываем про Firebird. СУБД одного уровня с PostgreSQL, как минимум. Моё субъективное мнение: Firebird лучше, но не настаиваю :))

>Какой в случае PostgreSQL и Linux использовать интерфейс пользователя? А какой хочешь. Есть ODBC / JDBC , а можешь и директом лезть. Для Linux есть и то и другое. Можешь С++, Pascal, Java и еще чего-то. С виндов через ODBC легко. Например делфи, или Си-билдер. Все прекрасно работате.

> Тестовое соединение было единственным (!), компьютер ничем, кроме
> постгресса, в этот момент не занимался. Запрос выполнялся в среднем
> 90 секунд.

Да уж.... Это серьезно :((( У меня самые сложные запросы идут с выборкой из 9 таблиц различными ждойнами сцепленными, и поск по куче полей (от 1 до 7 полей). Правда, я всегда пользуюсь limit offset, и больше 10 записей не беру. Баже в голову не приходило скорость мерить. Очень быстро отрабатывает. Хотя машинка помощнее будет.

>vada: Повторюсь, оптимизация структуры проводилась и не один раз.
>Как раз с учетом explain от самого сервера. Причем над каждым запросом
>работало несколько человек независимо друг от друга.

Да уж. Бяда. Извини. :((( Может собран сервер неудачно? Я свой под PIII точил. И сервачек у меня старый 7.1.3. С совместимотью ломаться не захотел. Были проблемы, а переписывать/отлаживать влом.

>Моё субъективное мнение: Firebird лучше, но не настаиваю :))

И не настаивай :)))

hbee, я конечно FireBird знаю по состоянию на полтора года назад, но когда я с неё слезал, она в подметки PostgreSQL не годилась, хотя для определенных задач FireBird весьма неплоха, при том, что с производительностью у неё швах иногда, не взирая на индексы (реально запрос по таблице с извлечением большой строки и сортировкой по дате (поле индексированно) выполнялся дольше аналогичного на тех же данных в PostgreSQL, где поле проиндекисровать я просто забыл --- 30 секунд против долей секунды)...

Вопрос анониму, сравнивающему оракл и Postgres: вроде как в исходном
утверждении от BigBug:

> Но например для крупных проектов PostgreSQL больше подходит, так как у
> мускула явно не хватает возможностей.

PostgreSQL сранивался с MySQL, а не с Oracle? Сколько времени при точно
таких же условиях выполняется запрос на MySQL?

2anonymous (*) (2003-02-10 17:06:02.005):
1. Поиграйтесь с индексами, там их много возможно вам подойдет другой индекс (GIST, r-tree, hash) для ускорения поиска и выборки.
2. Опции самого PostgreSQL меняли (буферы для сортировки и выборки)? Есть даже pgautotune, чтобы оптимально подобрать эти параметры - сам все в ручную всегда делал, так что ничего не обещаю.
3. Что там со swap - вы вообще смотрели что там загибается? Диск/Память/Процессор?
4. Очень часто (у меня в практике) увеличение ОЗУ и 2 пункта ускоряли PostgreSQL существенно.
5. Сравните организацию поиска в Oracle и PostgreSQL возможно так вы подберете идеальное сочетание по всем пунктам.
6. Вы читали HOWTO/FAQ по поводу выбора железа и тюнинга самого PostgreSQL от авторов системы?
7. Заоптимизируйте PostgreSQL под архитектуру сервера, например для P3: -march=686 для любого GCC>=2.95.
8. А что там за дистрибутив Linux? Может у вас Libc5???
9. Как организовано хранение информации? На RAID-e? На SoftRAID? На одном-двух дисках?

Видите очень много нужно сделать, чтобы не заплатить за Oracle, если вам лень или нет времени на это - платите и используйте.

С уважением, Олег.

P.S. Недавно смотрел Interbase 6.0.1 и Firebird ... IMHO очень далеко ему до PostgreSQL по speed/usability. Ex: сделайте такой запрос для любой таблицы в IB: insert into table select * from table;

P.P.S. Если правда нужно - напишите, я вам по почте попробую помочь бесплатно, ради принципа.

>>5000000 строк (и при этом около 60 полей самого разного типа).

Опс... тоесть, если я правильно понял, то в ОДНОЙ таблице 60 полей ??????
Если это так, тогда все остальное коментировать не имеет смысла, особенно про "несколько" человек....


Насчет оракла. пускать (8i или 9) в продакшен на 256М, мягко говоря, не разумно. Так что сравнивать собсно нечего. Ибо то, что оракл считает тестовыми базами, зачастую, для всех остальных считается пределом работоспособности, но и железо, увы, нужно соответсвующее.

кстати, знатоки постгресса, еcли я правильно понял, то в сабже уже существует explain ???? Раскажие пожалуйста поподробнее, а то у меня уже год в голове бродит идея попробовать postgreSQL, хотелось бы зарание знать чего в нем нету...

>>С виндов через ODBC легко.
можно поподробнее. Что легко? вытащить данные из таблицы в ексель??
если не только это, тогда расскажи мне как через ODBC работать с collection, ну или хотябы с курсорами..

У товарища с 5.000.000 и долгой выборкой скорее всего стоит 7.2.x в этой ветке "поломали" работу с часто изменяемыми индексами. Он забывает иногда подчищать свой мусор и для таблицы в 5Mb через n-е время может держать индекс в 500Mb. Соответственно и скорость падает офигенно, т.к. поиск по индексам на порядки становится медленней прямого просмотра всех записей. Лечится периодическим удалением/созданием индексов, что несложно сделать встроенной процедурой и вызывать ее из Crontab.

Для других веток подобного поведения не встречал.

2ifconfig:
Explain вроде как с 7 версии имеется. Удобная штучка. В 7.3.x добавленно много Oracle вкусностей (ftp://ftp.us.postgresql.org/README.v7.3):
* Schemas allow users to create objects in separate namespaces...
* Functions returning multiple rows and/or multiple columns are now much easier to use than before.
* PostgreSQL now supports prepared queries, for improved performance.
* PostgreSQL now records object dependencies, which allows improvements in many areas. "DROP" statements now take either CASCADE or RESTRICT to control whether dependent objects are also dropped.
* Functions and procedural languages now have privileges, and functions can be defined to run with the privileges of their creator.


еще. Если надумаешь все таки смотреть PostgreSQL было бы очень интересно узнать твое мнение.

to Korwin. Спасибо за инфо, читаю..

>>еще. Если надумаешь все таки смотреть PostgreSQL было бы очень интересно узнать твое мнение.

Да буду скорее всего. Правда не раньше апреля. Потому как увы, таки для некоторых проектов (требующих скорости), надо искать что-то бесплатное. Есть еще желание на sap посмотреть..

Для нетребующих, я собсно нашел hsqldb (pure java). Много чего умеет.

>Опс... тоесть, если я правильно понял, то в ОДНОЙ таблице 60 >полей ??????
>Если это так, тогда все остальное коментировать не имеет смысла, >особенно про "несколько" человек....

ifconfig, объясните плиз, какая зависимость между скоростью выбора
по полю от общего кол-ва полей в таблице ???

M.

здесь другая зависимость... если человек создаёт таблицы с 60 полями, скорее всего у него не очень хорошо с умением проектировать БД и работать с ними потом...

>если человек создаёт таблицы с 60 полями, скорее всего у него не очень хорошо с умением проектировать БД и работать с ними потом...

Не соглашусь. Иногда возникает необходимость в обработке таблицы с большим (20-30) количеством полей.

ifconfig: Та задача, которую я привел в качестве примера, как раз и требовала такого количества полей (ну не 60 - штук 30). Насколько я помню, излишняя декомпозиция - тоже вред.

60 полей , это недостаток(неумение ???) проектирования. И оправдательных аргументов здесь нет. Можно только ткнут носом в учебник. Таблицы в базе такой структуры практически всегда в ненормализованой форме. Что есть очень большой гиморой когда проект маштабируеться. Я даже молчу про элементарное удобство пользовать такие таблицы. Или вы настолько гениальны, чтобы запомнить в уме названия 60 полей? По крайней мере, когда я встречаю такие базы, то их авторы не могут дать внятного ответа почему сделано имеено так.


>>Та задача, которую я привел в качестве примера, как раз и требовала такого количества полей (ну не 60 - штук 30).

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

2ifconfig (*) (2003-02-11 18:09:56.141) Запросто.Конструкторская документация. Если взять какую-нибуть деталь хитрого вида. Хотя на счет большого кол-ва полей я с тобой согласен.

ifconfig

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

Элементарно. У одних только клиентов адресов, биков, иннов, кодов по ОКПО и ОКОНХ, и т.д./т.п. может быть легко как под 30 так и за 30 полей.. А еще и служебная инфа по клиенту (даты конца контракта, имя контактного менеджера и т.п.).. Короче, в легкую. Ты, надо полагать, сразу же предложишь для одной сущности по сорок табличек лепить: для банковских реквизитов одну, для служебных задач другую... ? ;-))))

>>У одних только клиентов адресов, биков, иннов, кодов по ОКПО и ОКОНХ
угу посчитай сначала, а потом говори.. в лучшем случае 10-12 признаков наберешь...

>>А еще и служебная инфа по клиенту (даты конца контракта, имя контактного менеджера и т.п.).

да ну??? и дату контракта тоже лепить в мастер таблицу справочника клиента???? у... уважаемый, сразу видно что вы не одну сотню комерческих заказов делали %))


>> Короче, в легкую
да ты пример приведи, полный (если не запаришся несуществующие признаки выдумывать), ну напиши типа
CREATE TABLE client (
id number
,fnaмe varchar2(31)
,sname varchar2(31)
,description clob
...
)
а я тебе потом напишу как это нужно делать %)
Это так, в простом варианте.

А если совсем грамотно, то ваще объекты лепить надо
create type person_t as object
(
fnaмe varchar2(31)
,sname varchar2(31)
...
...
)
/

create type client_t under person
(
okpo number
,....
)

create table clients_table
(
id number
,client_ client
...
)


Короче, со мной спорить можно в чем угодно, но только не в этом %) написание всевозможного учета, это одна из млих основных работ, и сколько признаков у клиента мне рассказывать не надо %)

-----------------------------

>>Конструкторская документация. Если взять какую-нибуть деталь хитрого вида.

ну и?? признаки этой детали не деляться на группы???
nested table ни о чем не говорит??

2ifconfig. Прекрати ты, все равно не поймут.
>Конструкторская документация. Если взять какую-нибуть деталь хитрого вида
Гы-гы. По таким заявлениям парень похоже для каждого типа детальки делает отдельную таблицу со свойственными ей атрибутами/полями. Забавно.

ifconfig

> А если совсем грамотно,

... то не у всех есть бабки на Оракл. :-))))

> и дату контракта тоже лепить в мастер таблицу справочника клиента????

А куда ее прикажете ??? В товары ? ;-)))

> да ты пример приведи, полный (если не запаришся несуществующие признаки выдумывать), ну напиши типа

Я запарюсь переписывать все имена полей, а в какой системной табличке самого MS SQL'a они хранятся - не знаю. :-)))

В базе, с которой я имею дело 30 полей, не считая idшника. Это именно всякие ОКОНХи и ОКПОхи, корреспондентские и расчетные счета и т.п. + служебная инфа с красноречивыми названиями byteKlentKind и т.п. По названиям - ко мне не придираться, не я делал базу ;-)))

> nested table ни о чем не говорит??

Мне и Sun Fire 3800 говорит. И знаешь, чего говорит ?? Что хрена лысого я его завтра у себя на работе увижу ;-))) "Так чта-а"...

2ifconfig Ну развалил ты инфу по нескольким таблицам, и что ? Просто вместо одной тэйблы у тебя - несколько. Кроме дополнительного гемора с отчётами, других фич не вижу.

>>Прекрати ты, все равно не поймут.

Вот это точно, 100 раз зарекался не ввязываться в бессмысленые споры, ах нет иногда таки "затягивает" %)

> Vacuum неэффективен, к сожалению.
vacuum full пробовали?=)
google & mnogosearch - оно рулез. у меня были аналогичные проблемы (см. архив рассылки pg-general).

> При этом оракловый сервер как раз и не был выделен исключительно под
> эту задачу
что, он тоже был PII-400/256/HDD IDE?8-)
я сильно сомневаюсь что оракл будет нормально на этом работать.;-)
so do postgres.;) один только нормальный буфер под сортировку займёт мегов 500. (5000000*60*ну байтов по 7 всяко) =~2.1G min
насилуете-то Вы животинку не по-детски.
постгрес, как и все СУБД, очень отзывчив на замену IDE->SCSI.
что говорил EXPLAIN?
BTW, планировщики у Оракла и постгреса работают по-разному.

> Читал, что MySQL поддерживает и koi8-r и cp1251
у постгреса есть charset_recode
к базам обоих можно обращаться через ODBC - у нас так виндозники ходили к Pg и mysql.