hvlad Зл0й hvladВнимание, вопрос : а где указание на прямую зависимость между дизайном одной подсистемы и производительностью целой системы ?

Ну так, а напряжометр на что? Померить сколько происходит i/o может любой мало-мальски грамотный администратор СУБД, обладающий хотя бы минимальными навыками системного администрирования. Если у вас на диске "бардак валяется" в виде многочисленных версий записи, то поскольку все современные (не мэйнфреймовые) ОС читают-пишут или блоками или группами блоков, то постгрес будет тащить в оперативную память кучу никому не нужного мусора. При типичных задачах большинство современных СУБД "затыкаются" именно на том что пропускной способности i/o подсистемы не хватает. Тут ежу понятно что происходит, никакой "ракетной науки" как говорится.Это всё не так прямолинейно, как хотелось бы. Есть ODS, а есть конкретные релизации, работающие с ней. Хаять ODS из-за не эффективного кода не совсем хорошо.

Я в общем-то хаял не конкретную реализацию этого хозяйства в PG, а идеологию того как MVCC в нем поддерживается. Идея на мой взгляд совершенно тухлая, и как вы ее реализацию не вылизывайте, как не оптимизируйте код, результат будет хреновый.

hvlad
Ну а если уж ODS настолько крива, что эффективный код с ней написать не возможно, то тогда её меняют.

О чем собственно и речь. На мой взгляд "кривизна" этой идеи очевидна. Только вряд ли кто-то исправлением этой кривизны будет заниматься - придется много чего переписать.

hvlad
Но я не советую называть слепыми идиотами тех, кто достаточное кол-во лет посвятил разработке именно такой ODS и работе с ней. Они прекрасно понимают её недостатки и достоинства и видят несколько больше нюансов, здесь даже не упоминаемых.

Я никого идиотом не называю. Идиотская идея. Даже такому известному и авторитетному специалисту как Майкл Стоунбрэйкер бывают в голову приходят завиральные идеи. Ни в одной из СУБД над которыми он работал, ни до ни после PG он эту идею не использовал. Ни Ingres ни Illustra ни Informix не имеют такого. Они вообще помоему MVCC не поддерживают.

hvlad
Я не знаю деталей ODS в PG, но могу делать предположения, исходя из своего скромного опыта работы над FB.

FB неплохая СУБД но она пока еще не доросла до того уровня когда хранение данных по принципу "бардак валяется" станет проблемой. Дай Бог чтобы она доросла до этого уровня, тогда вам придется с этой проблемой воевать.


hvlad
Зл0йА зачем версионность на уровне записи если с диска читаем и пишем блок (или кучу блоков за один системный вызов)? Не про блокировку ведь речь.Дабы меньше этих блоков нужно было писать, читать и держать в памяти.

То есть мы притащили с диска блок с дюжиной записей, достали пару-тройку нужных нам сейчас записей, положили их в кэш а остальное выкинули чтобы не хранить почем зря в памяти? Что-то у меня производительность и дальновидность такого подхода вызывает определенные сомнения. Особенно учитывая что самый критический для производительности большинства современных СУБД ресурс - это i/o, в него упираются чаще всего. А память вещь недорогая, у меня в ноутбуке ее 4 гига. Производительность процессоров и объемы оперативной памяти растут гораздо быстрее чем скорость дисков.

hvlad
Зл0йНу так сравнивать же с чем-то надо.Сравнивать - это хорошо. Но делать выводы про A, на основе знаний о B - как минимум не корректно.
Ну почему же, я когда с мотоцикла Урал сажусь на полицейский мотоцикл Kawasaki KZ1000P то сравнение как-то само собой получается не в пользу Урала. Потому что 88 л.с. против 36 и двухдисковый передний тормоз против барабанного разработки 1939г. Достаточно пару раз прокатиться и сразу все понятно. С СУБД такая же фигня. Мне очень хочется иметь высокопроизводительную оупенсорсную СУБД. Я не зацикливаюсь на Oracle с DB2. К сожалению по опыту "езды" PG - это Урал-совнархоз а Оракл это Yamaha R1 (современный литровый супербайк). Если PG перестанет быть Уралом и дотянется хотя бы до уровня японских мотоциклов 80х годов я с большим удовольствием буду его использовать.