PostgreSQL v7.3.3 is out

> 1. Переписать на чистый SQL с использованием тех же TEMP TABLE? Известно, что SQL-функции зачастую работают на порядок быстрее PL/pgSQL

Хм, а не это ли всю дорогу утверждала команда mysql? ;))

2last anonymous. Нет не это утверждала команда mySQL. Определимся со следующими возможными вариантами. Реализация необходимой логики след. средствами:
1. SQL функциями.
2. SQL запросами.
3. PL/pgSQL функциями.
4. В случае невозможности реализации через прямой SQL часть логики берет на себя Application либо AP.

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

Так вот. В контексте данного обсуждения утверждение saper выглядит совершенно коректным. Имеется ввиду функция SQL, а не SQL запрос. Так что бурчание команды mySQL опять мимо тазака :)

2Alter

>А как дела с документацией по JBOSS обстоят, могли бы подсказать?

Фигово. :((( Документация в инет есть, но для старых версий. Многое переделано, и работает не так как раньше. Все методом эксперементов. Проб и ошибок. После пасов с бубном, курением травы и пением гнусным голосом песен, заработало вполне прилично.

Ok, спасибо за советы, что-нибудь придумаем ;)

Конечно, если писать/читать lor в 2-4 часа утра по мск, когда на нем минимальная нагрузка, то никаких тормозов неувидишь ;)

Согласно твоему определению, когда мы работаем с диском в PIO моде, чтение одного сектора - это 512+ I/O операций.

Прямые обращения в терминах чего уменьшаются? В терминах размера I/O - нинасколько. В терминах выданных диску команд - раз примерно так в 8.

to Korwin

>>1. SQL функциями.
......

прочитал все вышенеаписанное, подчерпнул для себя немало интересного, ну кроме "разговоров про MySQL".

Собсно есть вопросец, а существует ли в постгрес понятие,
разделение типов конекта на shared/dedicated ?
и поняти "втаскивать" при открытиии конекта в память наиболее вероятно употребимый клиентом куски pl/pgsql кода?


К грину, что то мне подсказывает, что 512М памяти как то стремновато по нонешним временам. И, насколько, я понимаю, то есть что-то из разряда BX ?? Хорошие были чипы, но к сожалению 5 лет назад, если речь идет о не SCSI харде, то скорость IDE в чипах ветки P4 ушла за это время далеко вперед, что я собсно и хорошо замечаю на базах где объем данных привышает значительно SGA.

Да, 512M памяти стремновато. Но текущая мамка больше не держит (i815). Именно поэтому я подумываю прикупить что-нибудь более приличное в ближайшее время. Если у кому денег нежалко - присылайте мне ;) Чем больше будет денег, тем круче железки.

> 1. SQL функциями. > 2. SQL запросами. > 3. PL/pgSQL функциями. > 4. В случае невозможности реализации через прямой SQL часть логики берет на себя Application либо AP. > Варианты перечисленны в порядки убывания быстродействия.

Гражданин как обычно забывает самый быстрый вариант - 0. SPI-функции..

2Korwin (*) (2003-05-31 11:56:34.619335)

>2) Написание C/C++ функций для работы с XML внутри БД и для > кеширования исп. временные таблицы.

Я уже писал об этом. Есть такая приблуда /contrib/xml Но она не очнь...

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

Дауж... :((( А что в качестве AS?

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

Вот ежели бы еще сообщения в стиле MySQL rulezzzz выфильтровывать....
эх мечты мечты...

2 green (*) (2003-05-31 19:49:09.484034)
> Внимательно готов выслушать все советы по настройке базы...
Может, имеет место та же проблема, что и у этих товарищей (не создается индекс по 'int8', даже если указан; стр.48-49)
http://www.theserverside.com/resources/pdf/tss_architecture.pdf

satyr.

> Вот ежели бы еще сообщения в стиле MySQL rulezzzz выфильтровывать....

Да ты просто боишься ;) Давай еще проверим.

# MySQL Server is generally much faster than PostgreSQL. MySQL 4.0.1 also has a query cache that can boost up the query speed for mostly-read-only sites many times.

# MySQL has a much larger user base than PostgreSQL. Therefore, the code is tested more and has historically proven more stable than PostgreSQL. MySQL Server is used more in production environments than PostgreSQL, mostly thanks to the fact that MySQL AB, formerly TCX DataKonsult AB, has provided top-quality commercial support for MySQL Server from the day it was released, whereas until recently PostgreSQL was unsupported.

# MySQL Server works better on Windows than PostgreSQL does. MySQL Server runs as a native Windows application (a service on NT/2000/XP), while PostgreSQL is run under the Cygwin emulation. We have heard that PostgreSQL is not yet that stable on Windows but we haven't been able to verify this ourselves.

# MySQL has more APIs to other languages and is supported by more existing programs than PostgreSQL. See section B Contributed Programs.

# MySQL Server works on 24/7 heavy-duty systems. In most circumstances you never have to run any cleanups on MySQL Server. PostgreSQL doesn't yet support 24/7 systems because you have to run VACUUM once in a while to reclaim space from UPDATE and DELETE commands and to perform statistics analyses that are critical to get good performance with PostgreSQL. VACUUM is also needed after adding a lot of new rows to a table. On a busy system with lots of changes, VACUUM must be run very frequently, in the worst cases even many times a day. During the VACUUM run, which may take hours if the database is big, the database is, from a production standpoint, practically dead. Please note: in PostgreSQL version 7.2, basic vacuuming no longer locks tables, thus allowing normal user access during the vacuum. A new VACUUM FULL command does old-style vacuum by locking the table and shrinking the on-disk copy of the table.

# MySQL replication has been thoroughly tested, and is used by sites like:

* Yahoo Finance (http://finance.yahoo.com/)
* Mobile.de (http://www.mobile.de/)
* Slashdot (http://www.slashdot.org/)

Наслаждайся, теоретик.

int8 нигде не используется, как я понимаю. просто integer (который есть int4 вроде как).

anonymous (*) (2003-06-02 13:02:55.363529):

> MySQL Server is generally much faster than PostgreSQL.

'generally' здесь переводится как 'в тестах, котрые мы сами и пишем'

> MySQL 4.0.1 also has a query cache that can boost up the query speed for mostly-read-only sites many times.

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

> MySQL has a much larger user base than PostgreSQL. Therefore, the code is tested more and has historically proven more stable than PostgreSQL.

1) '10 миллионов леммингов не могут быть неправы'

2) 'Windows 98 has a much larger user base than Linux. Therefore, the code is tested more and has historically proven more stable than Linux'

> MySQL Server is used more in production environments than PostgreSQL, mostly thanks to the fact that MySQL AB, formerly TCX DataKonsult AB, has provided top-quality commercial support for MySQL Server from the day it was released, whereas until recently PostgreSQL was unsupported.

Себя не похвалишь --- весь день как обосранный ходишь.

> MySQL Server works better on Windows than PostgreSQL does. MySQL Server runs as a native Windows application (a service on NT/2000/XP), while PostgreSQL is run under the Cygwin emulation.

Единственное правдивое утверждение касательно PostgreSQL...

> We have heard that PostgreSQL is not yet that stable on Windows but we haven't been able to verify this ourselves.

'Одна бабка сказала, что...'

> MySQL has more APIs to other languages

...поэтому труднее выбрать нужный API

> and is supported by more existing programs than PostgreSQL

Большинство из которых написано на PHP вчерашними веб-дизайнерами

> PostgreSQL doesn't yet support 24/7 systems because you have to run VACUUM once in a while to reclaim space from UPDATE and DELETE commands and to perform statistics analyses that are critical to get good performance with PostgreSQL.

а как насчёт (цитата из мануала MySQL):

OPTIMIZE TABLE should be used if you have deleted a large part of a table or if you have made many changes to a table with variable-length rows (tables that have VARCHAR, BLOB, or TEXT columns). Deleted records are maintained in a linked list and subsequent INSERT operations reuse old record positions. You can use OPTIMIZE TABLE to reclaim the unused space and to defragment the datafile.

> ... Please note: in PostgreSQL version 7.2, basic vacuuming no longer locks tables, thus allowing normal user access during the vacuum. A new VACUUM FULL command does old-style vacuum by locking the table and shrinking the on-disk copy of the table.

Зачем рассказывать старые страшные сказки, если сами признают, что в версии 7.2 (текущая --- 7.3) всё нормально работает?

> MySQL replication has been thoroughly tested, and is used by sites like:

домен .org поддерживается системой на основе PostgreSQL, где используется коммерческое решение для репликации. Есть вполне работающие opensource решения.

>>Да ты просто боишься ;) Давай еще проверим.
точно, боюсь.. %) можешь себе на корочке так и записать.

А еще, рекомендую в resume вписывать эту же фразу, а потом пытатся с ним устроить с ним на работу IT отдел комерческой структуры. Некоторые менеджеры сразу такие резюме в корзину отправляют, некоторые, как я к примеру, при хорошем настроении, устраивают "избиение младенцев", задавая вопросы о том, как тваришь будет строить базу, или реализовывать алгоритм сложнее "тупо вставил, тупо прочитал". Я тут эпизодически такие вопросы задаю, как то сразу все стихают, некоторые кричат что нам это не нужно.. К примеру вьюверы.
Я разве против, не нужно так не нужно. Зарабатывайте деньги самостоятельно. Хотите идею.. Напишите ERP на своем любимом сервере таблиц.


блин, а когда нибудь можно понять что скорость атомарных операций это еще не все критерии выбора СУБД ?
Про скорость, тут уже упоминали про проблему INSERT/SELECT, я же рекомендуюю посмотреть на нагруженные phpBB форумы, с числом активных коннектов >=100 и базой больше чем в пол-гига..

ifconfig (*) (2003-06-02 14:37:11.310992):

> я же рекомендуюю посмотреть на нагруженные phpBB форумы, с числом активных коннектов >=100 и базой больше чем в пол-гига..

ээх... мечта идиота --- сделать родную PostgreSQL версию phpBB. Должно работать разиков так в несколько быстрее, если заставить базу делать часть всей той херни, которую там делает PHP (сбор статистики, каскадное удаление, etc).

Объём работы, правда, немаленький понадобится, зато какие рожи будут потом у фанатов ихSQL!

> а потом пытатся с ним устроить с ним на работу IT отдел комерческой структуры.

Фи, какая низость. В страшном сне только может приснится: я работаю в IT отделе какой-нибудь шараги с надутыми как индюки шефами и тупорылыми до безобразия юзверями. Бррррр... Сразу срыгнул.

> некоторые, как я к примеру, при хорошем настроении, устраивают "избиение младенцев"

Начали. Избивай. Только жилет пуленепробиваемый одеть незабудь ;)

> Про скорость, тут уже упоминали про проблему INSERT/SELECT,

... а я привел факты, говорящие о том, что "проблема" не существует.

> я же рекомендуюю посмотреть на нагруженные phpBB форумы

А с чем ты сравниваешь? Вот то-то и оно... Крутой спец говоришь? Хошь я тебя в грязь превращу? ;)

>>Хошь я тебя в грязь превращу? ;)

Ты для начала имя свое напиши, и должность..
потом будешь шуметь...

А без имени и должности избить не сможешь? ;)

>> MySQL Server is generally much faster than PostgreSQL.

>'generally' здесь переводится как 'в тестах, котрые мы сами и пишем'

Нет! 'generally' здесь переводится как 'всегда, за исключением
клинических случаев, когда код пишет человек, не понимающий,
что он делает'. Далеко ходить не будем. В этом треде нам уже
продемонстрировали код г-на maxcom'a, над которым сейчас в поте
лица работает месье green.

Ведь нормальный трейд был, что редко на LOR бывает. Но вот ананимус со своим офтопиком влез. :((( Ну и все. Пошло кидание жидким стулом. А жаль.

vada (*) (2003-06-02 16:17:21.566956):

> Ведь нормальный трейд был, что редко на LOR бывает. Но вот ананимус со своим офтопиком влез.

а у него комплекс неполноценности разыгрался... дети! такое будет с каждым, кто долго пользуется mysql!

>>А без имени и должности избить не сможешь? ;)
А смысл? будет имя, засветишься в Инете, твой будушей работодатель найдет по гугелю..
А так, я уже нескольок раз это делал, поишти в истории..

Я точно знаю, что ничего интересного никакой работодатель не найдет в гугле, набрав в поиске 'ifconfig' ;)

На 'Drobov Pavel' самая интересная ссылка - http://marc.theaimsgroup.com/?l=wget&m=102810214425600
На товарисча с таким английским языком, и так издагающего свои мысли работодатели наверное строятся в очередь ;) Впрочем... город Днепропетровск... почему бы и нет...

>> http://marc.theaimsgroup.com/?l=wget&m=102810214425600
у тебя есть конкретные замечания к моему английскому? я никогда не утверждал что он идеален, но вполне сносен для понимания. По крайней мере, то куда ты указал, прочитали, и патчик сделали. Причем не переспрашивая..
И во-вторых, я по русски пишу еще хуже. Это мне как-то не мешает зарабатывать себе на хлеб.

По поводу работодателей, Я УЖЕ давным давно себе сам на хлеб зарабатываю, да еще даю работу другим. Так что в очередь я никогда не стоял %)

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

anonymous (*) (2003-06-02 16:13:00.294145):

>> 'generally' здесь переводится как 'в тестах, котрые мы сами и пишем'

> Нет! 'generally' здесь переводится как 'всегда, за исключением клинических случаев, когда код пишет человек, не понимающий, что он делает'. Далеко ходить не будем. В этом треде нам уже продемонстрировали код г-на maxcom'a, над которым сейчас в поте лица работает месье green.

Кстати Ананимус замечательно подтвердил мою мысль: Postgres-то на сайте тормозил, потому, что его хреново настроили. Остаётся только пораскинуть мозгами: а как ещё могут его настроить люди, которые больше всего хотят своими тестами доказать, что он медленно работает?

Для совсем тупых: намекаю на авторов мануала MySQL.

>Собсно есть вопросец, а существует ли в постгрес понятие,
>разделение типов конекта на shared/dedicated ?
>и поняти "втаскивать" при открытиии конекта в память наиболее вероятно
>употребимый клиентом куски pl/pgsql кода?
Насколько понял вопрос, то этого в PostgreSQL нет и пока не предвидится.

Кеширование SQL запросов есть, оптимизация и кеширование результатов PL/pgSQL кода есть.

>>В качестве решения к каждой записи с XML документом храню время его >>изменения, а в AS храню DOM. Но такой подход в ряде случаем не удобен, >> а иногда просто не применим.
>Дауж... :((( А что в качестве AS?
В качестве AS свой собственно написанный на Java. Вообще-то он многое чего делает и это в том числе. Ко всему прочему умеет кешировать результаты запросов в свой встроенный hsqldb SQL-сервер - это на случай если работа с ДБ идет не локально, и требуется максимальное уменьшение трафика.

>>Насколько понял вопрос, то этого в PostgreSQL нет и пока не предвидится.

Понял, спасибо. завтра попытаюсь полезть во внутря и доки постгресса более глубоко.

Вообщето, втягиванием кода в SGA я тоже долго пренебрегал, это начинает активно сказываться при большом количестве клиентов.

>>результаты запросов в свой встроенный hsqldb SQL-сервер
кстати, я ода полтора назад делал что-то похожее. работает...


P.S. Ща себя (выше) читаю, и думаю накой опять ввязываюсь в бесполезные дебаты с анонимусами %)).

> и думаю накой опять ввязываюсь в бесполезные дебаты с анонимусами %)).

Да где же ты ввязался? Стращал избиением, а как пугнули слегка, сразу описялся в штанишки ;)

>> и думаю накой опять ввязываюсь в бесполезные дебаты с
>> анонимусами %)).
>Да где же ты ввязался? Стращал избиением, а как пугнули слегка, сразу
>описялся в штанишки ;)
Этот анонимус только подтверждает слова ifConfig'а. С ними бесплезно вести какие-нибудь дебаты, т.к. они быстро теряют нить обсуждения и не имеют никакой логики в своих суждениях.
Воистину, ребята онанимусы, бросайте вы MySQL, его использование плохо сказывается на ваших способностях к рассуждениям :)

Тут собрались ГУРУ!
Поделитесть информацией, если кто в курсе, что из себя будет представлять поддержка Java в Postgres?

> т.к. они быстро теряют нить обсуждения и не имеют никакой логики в своих суждениях.

Окстись, защитник прав сексуальных меньшинств. Логика в постах
железная, но тебе она видимо недоступна. Те, кому она доступна,
спрятались в кусты и молчат в тряпочку. Ибо возразить им нечего.

anonymous (*) (2003-06-03 11:09:33.990738):

> Те, кому она доступна, спрятались в кусты и молчат в тряпочку. Ибо возразить им нечего.

Кстати о кустах. Что ж ты, чмо, на мои посты ничего не ответил? Или своих мозгов уже нет, голова как опилками мануалом да пресс-релизами от MySQL забита?

Сорри, я забыл про воинствующих идиотов ;( Да, точно, не
отвечаю. Им же лень прочесть мануал про тот же query cache,
который прекрасно управляется сервером приложений. Что же я
буду пересказывать? Нет, не буду.

anonymous (*) (2003-06-03 16:36:25.439808):

> Им же лень прочесть мануал про тот же query cache

сам не ожидал насколько я прав насчёт опилок оказался.

объясни мне, ламерок: зачем гонять запросы от приложения (сервера приложений) к базе и результаты в обратную сторону, тратя на это ресурсы, если можно кэшировать на уровень выше?

у меня есть два варианта ответа:

1) затем, что пользователи MySQL настолько тупы, что сами реализовать алгоритм кэширования не в состоянии;

2) чтобы выигрывать тупые бенчмарки.

я раньше склонялся ко второму варианту, но после общения с тобой...

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

Всем спасибо за настройку, сайт действительно стал заметно живее :-)

привет всем,

пока только знакомлюсь с Postgres v7.3.2 под Debian. кто подскажет литературу на русском/немецком и какой максимальный размер базы при инсталляции по умолчанию

<< Может это руки, но рестор после дампа, зачастую, дает другой результат по сравнению с тем,что было раньше. Искать такие ошибки очень трудно. Один раз я остался без первичного ключа. Второй раз он CHAR махнул на VARCHAR и у меня отлаженные части программы просто перестали работать. попробуй pg_dump "dbname" с соот. парам. | psql "dbname" и без restore работает и вроде типы не меняет

<<- потом, не нашел, как восстановить, ну например, дропнутую таблицу. Иногда руки быстрее головы работаут, что создает проблемы :))) Надеюсь, такая продлемма есть у многих, если не у всех. проблема очень веселая, только это стандарт DDL-SQL еще с незапамятных времен :) есть альтернативы TRUNCATE table удаляет строки и освобождает память (если это поможет ;) данные всеравно теряются безвозвратно, но хотя бы структура таблицы остается.

Народ подскажите как в PSQL обойти разрезку базы на куски по 2 гига ???

Хех - а Berkeley DB пашет однозначно быстрее - правда и траханины с ней больше - писать приходится .... :)

Скажите, кто знает, когда наконец Postrgres начнет поддерживать 
наследование PK/FK с наследованием таблиц? Давно обещают, только фичи 
этой все нет и нет. Может подскажет кто, какие 'доморощенные' решения 
такой задачи существуют?

Вот пример задачки:

CREATE TABLE Abstract (
id INTEGER PRIMARY KEY,
attr TEXT);

CREATE TABLE Source (
id INTEGER PRIMARY KEY,
abstract INTEGER REFERENCES Abstract(id),
attr TEXT);

CREATE TABLE Concrete(
concrete_attr TEXT
) INHERITS (Abstract);


INSERT INTO Concrete  VALUES (1, "attr_value", "concrete_value");
INSERT INTO Source (id, abstract, attr) VALUES (1, 1, "qweqweq");

Последний, очевидно, не работает.