Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Сравнение СУБД Новый топик    Ответить
Топик располагается на нескольких страницах: Ctrl  назад   1 [2] 3 4 5   вперед  Ctrl      все
 Re: Firebird vs Postgres  [new]
FreemanZAV
Member

Откуда:
Сообщений: 2434
Senya_L
И как справляется с версиями Posgres по сравнению с FB? Про сборку говорили ... и то вручную.

Не верится, что в postgre всё так плохо
28 ноя 08, 14:09    [6500247]     Ответить | Цитировать Сообщить модератору
 Re: Firebird vs Postgres  [new]
Yo.!
Guest
Senya_L
И как справляется с версиями Posgres по сравнению с FB? Про сборку говорили, что только недавно стало возможным сборка вне монопольного режима и то вручную.

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

Senya_L

Не совсем понятно, что вы понимаете под словом "неконсистентный"? Если что-то имеете против против уровня изоляции READ COMMITED у версионника, то совершенно напрасно. Из прочтения мануала понял, что в Postgres'е два уровня, причем низший сответствует SNAPSHOT у FB, а второй to SNAPSHOT TABLE STABILITY. Маловато будить (С) Мультик :)

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

другие языки в сторед процедурах постгрес вроде как более на CLR были похожи, но еще совсем недавно в совсем эксперементальном виде, может конечно что-то изменилось с тех пор ...
28 ноя 08, 14:11    [6500271]     Ответить | Цитировать Сообщить модератору
 Re: Firebird vs Postgres  [new]
kdv
Member

Откуда: iBase.ru
Сообщений: 30285
в PGSQL 8.3 есть ReadCommitted, и как утверждает документация
"In effect, a SELECT query sees a snapshot of the database as of the instant that
that query begins to run.", правда, тут проверять надо.

кстати, снапшота я пока у них не наблюдаю, может не дочитал. Зато есть сериализуемый уровень изолированности. что они там имеют в виду, не очень понятно, т.к. документация написана "вольным" стилем и отсылок на стандарт я не вижу.
28 ноя 08, 14:12    [6500276]     Ответить | Цитировать Сообщить модератору
 Re: Firebird vs Postgres  [new]
Yo.!
Guest
2кдв

сериализабле это и есть снепшот, определение которого все таки добавили в стандарт. суда по доке все как в оракле, все запросы видят данные на момент старта транзакции, блокировки пишущих транзакций живут доконца транзакции.
28 ноя 08, 14:21    [6500343]     Ответить | Цитировать Сообщить модератору
 Re: Firebird vs Postgres  [new]
Dimitry Sibiryakov
Member

Откуда:
Сообщений: 54840

Yo.!

READ COMMITED там был такой же как в орале, т.е. как у обычного версионника.

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

Posted via ActualForum NNTP Server 1.4

28 ноя 08, 14:22    [6500359]     Ответить | Цитировать Сообщить модератору
 Re: Firebird vs Postgres  [new]
kdv
Member

Откуда: iBase.ru
Сообщений: 30285
Yo
в постгрес процедура вакум всегда был отдельный процесс, в ФБ почему то вакумом занимались юзерские сесии которые вместо того чтоб выдать запрошеный результат пользователю чистили версиии оставшиеся от других. как я понял в последних версиях поведение ФБ все же стало более походить на постгрес.

не "почему то", а потому, что дешевле собирать мусор мелкими кусками, а не ждать пока версий наплодится столько, что придется sweep запускать. И это есть практический факт, проверенный годами.
В FB 2.0 SuperServer введено 2 новых вида пользовательской сборки мусора, кроме имеющейся фоновой - принудительная как в Classic, и комбинированная.

Наоборот, у постгреса появился autovacuum, который похож на фоновую сборку мусора в FB Superserver, причем вроде как сразу несколько "workers" могут лазить и подбирать мусор.

Вообще все это на мой взгляд в постгресе слишком усложнено, настраивать запаришься. Согласен, что под высокой нагрузкой можно получить выигрыш, но...
28 ноя 08, 14:28    [6500401]     Ответить | Цитировать Сообщить модератору
 Re: Firebird vs Postgres  [new]
Yo.!
Guest
Dimitry Sibiryakov

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


такой read commited в oracle, mssql, mysql/innodb&falcon, postgres, т.е. в любом другом версионнике. зачем не конститентная каша блокировочнику - понятно, от бедности, repeatable read задыхается в блокировках с дедлоками, но нафига эта каша в верионнике ФБ я пока не понял, ладно кажется там (в ФБ) снепшот все таки по дефолту импользуется.
28 ноя 08, 14:34    [6500444]     Ответить | Цитировать Сообщить модератору
 Re: Firebird vs Postgres  [new]
LeXa NalBat
Member

Откуда: Москва
Сообщений: 2892
FreemanZAV
Senya_L
И как справляется с версиями Posgres по сравнению с FB? Про сборку говорили ... и то вручную.
Не верится, что в postgre всё так плохо
автоматическая сборка мусора autovacuum была добавлена в постгрес в версии 8.1, до этого существовала как дополнительный модуль.
28 ноя 08, 14:41    [6500503]     Ответить | Цитировать Сообщить модератору
 Re: Firebird vs Postgres  [new]
kdv
Member

Откуда: iBase.ru
Сообщений: 30285
Yo
но нафига эта каша в верионнике ФБ я пока не понял

все очень просто. До того как Борланд купил InterBase в IB был только один уровень изолированности - SNAPSHOT (ну и вариация с блокированием таблиц).
RC в IB внедрял уже Борланд. Ну и внедрили вот так, неаккуратно. Впрочем, я уже подробно писал
об этом и что я думаю по поводу "неатомарности селекта в RC"
вот тут
https://www.sql.ru/forum/actualthread.aspx?tid=173455&pg=2
28 ноя 08, 14:53    [6500570]     Ответить | Цитировать Сообщить модератору
 Re: Firebird vs Postgres  [new]
FreemanZAV
Member

Откуда:
Сообщений: 2434
Yo!
в постгрес процедура вакум всегда был отдельный процесс, в ФБ почему то вакумом занимались юзерские сесии которые вместо того чтоб выдать запрошеный результат пользователю чистили версиии оставшиеся от других.


В ib и в fb соответсвенно давно существует возможность не собирать мусор пользовательским сессиям.
28 ноя 08, 14:53    [6500572]     Ответить | Цитировать Сообщить модератору
 Re: Firebird vs Postgres  [new]
Dimitry Sibiryakov
Member

Откуда:
Сообщений: 54840

Yo.!
такой read commited в ... mssql

ЕМНИП, у этого "нормального версионника" read commited позволяет читать
(READ) незакоммиченные (UNCOMMITED) изменения других транзакций.

Posted via ActualForum NNTP Server 1.4

28 ноя 08, 15:05    [6500658]     Ответить | Цитировать Сообщить модератору
 Re: Firebird vs Postgres  [new]
Yo.!
Guest
Dimitry Sibiryakov

ЕМНИП, у этого "нормального версионника" read commited позволяет читать
(READ) незакоммиченные (UNCOMMITED) изменения других транзакций.

у mssql2k5 есть read_commited_snapshot, речь о нем. грязное чтение на блокировочном read commited - даже при всех ляпов мсскл не верю, вы случайно не путаете с приколом когда можно прочитать данные строки из индекса в то время как на строку наложена эксклюзивная блокировка ?
28 ноя 08, 15:29    [6500877]     Ответить | Цитировать Сообщить модератору
 Re: Firebird vs Postgres  [new]
Dimitry Sibiryakov
Member

Откуда:
Сообщений: 54840

Yo.!
даже при всех ляпов мсскл не верю

Тоже мне, Станиславский...

Posted via ActualForum NNTP Server 1.4

28 ноя 08, 15:37    [6500948]     Ответить | Цитировать Сообщить модератору
 Re: Firebird vs Postgres  [new]
Yo.!
Guest
Dimitry Sibiryakov

Тоже мне, Станиславский...

ну тады воспроизводимый пример кода в студию или мусье лишь ворочить языком горазд ?
28 ноя 08, 15:43    [6500995]     Ответить | Цитировать Сообщить модератору
 Re: Firebird vs Postgres  [new]
Dimitry Sibiryakov
Member

Откуда:
Сообщений: 54840

Yo.!
ну тады воспроизводимый пример кода в студию

А оно мне надо - ставить эту гадость только для того, чтобы создать
воспроизводимый пример документированного поведения:
BOL
READ COMMITTED

Specifies that shared locks are held while the data is being read to
avoid dirty reads, but the data can be changed before the end of the
transaction, resulting in nonrepeatable reads or phantom
data
. This option is the SQL Server default.

Posted via ActualForum NNTP Server 1.4

28 ноя 08, 15:57    [6501130]     Ответить | Цитировать Сообщить модератору
 Re: Firebird vs Postgres  [new]
Yo.!
Guest
2Dimitry Sibiryakov

жесть ...
даже и не знаю как на пальцах объяснить ... в процетированом куске речь идет о феноменах, это чуток другой природы явления нежели грязные (uncommitted) данные данные. менно эти феномены к стате говоря и вылазят в ФБ на read committed, но появление этих феноменов не означает, что возникнет способность прочесть грязные данные. нельзя в мсскл получить грязное чтение на read committed.
28 ноя 08, 16:35    [6501459]     Ответить | Цитировать Сообщить модератору
 Re: Firebird vs Postgres  [new]
Dimitry Sibiryakov
Member

Откуда:
Сообщений: 54840

Yo.!

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

Да неужели?
BOL
phantom
By one task, the insertion of a new row or the deletion of an existing
row in a range of rows previously read by another task that has not
yet committed its transaction
. The task with the uncommitted
transaction cannot repeat its original read because of the change to the
number of rows in the range.

Заметь, наличие коммита в "one task" никак не обозначено.

Posted via ActualForum NNTP Server 1.4

28 ноя 08, 17:25    [6501870]     Ответить | Цитировать Сообщить модератору
 Re: Firebird vs Postgres  [new]
Yo.!
Guest
Дмитрий, есть туча лит-ры для начинающих где эти феномены разжеваны. в этом куске речь идет о том, что второй стейтмент в транзакции может прочесть те данные, которые не видел первый стейтмент. но на уровне RC эти новые данные по любому закомиченые данные, которые были закомичены другой транзакцией, просто уже после того как выполнился первый стейтмент первой транзакции.
28 ноя 08, 18:14    [6502183]     Ответить | Цитировать Сообщить модератору
 Re: Firebird vs Postgres  [new]
Senya_L
Member

Откуда: Москва
Сообщений: 5381
LeXa NalBat
FreemanZAV
Senya_L
И как справляется с версиями Posgres по сравнению с FB? Про сборку говорили ... и то вручную.
Не верится, что в postgre всё так плохо
автоматическая сборка мусора autovacuum была добавлена в постгрес в версии 8.1, до этого существовала как дополнительный модуль.
Предвидел, что холивар неизбежен, но надеюсь все ж таки полезное отфильтровать :)
А как с производительностью запросов обстоит дело у в постгрес?
28 ноя 08, 22:33    [6502856]     Ответить | Цитировать Сообщить модератору
 Re: Firebird vs Postgres  [new]
Senya_L
Member

Откуда: Москва
Сообщений: 5381
Yo.!
2Dimitry Sibiryakov

жесть ...
даже и не знаю как на пальцах объяснить ... в процетированом куске речь идет о феноменах, это чуток другой природы явления нежели грязные (uncommitted) данные данные. менно эти феномены к стате говоря и вылазят в ФБ на read committed, но появление этих феноменов не означает, что возникнет способность прочесть грязные данные. нельзя в мсскл получить грязное чтение на read committed.
вы так душевно объясняете, шо не могу не встрять. :)
Я так и понял, чем нормальный, "рабочий" read comimted в Firebird вам не угоден? И вообще это похоже на религиозный бред. Я про
Yo.!
но нафига эта каша в верионнике ФБ я пока не понял
Если это УДОБНО и РАБОТОСПОСОБНО, то зачем выЁживаться? Только потому что в это ветке вам в чем то надирали зад поклонники FB? Подходя к вопросу разумно: без такой "каши", чтобы увидеть изменения, сделаные в других транзакциях, надо делать запустить новую транзакцию (надеюсь, понятно выражаюсь). Нафига? Если плохо понятно устройство версионной архитектуры БД (мне, честно говоря, тоже не очень :)), то может не стОит загоняться
29 ноя 08, 00:02    [6503102]     Ответить | Цитировать Сообщить модератору
 Re: Firebird vs Postgres  [new]
Yo.!
Guest
Senya_L

Я так и понял, чем нормальный, "рабочий" read comimted в Firebird вам не угоден? И вообще это похоже на религиозный бред.

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

Senya_L

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

угу, предельно понятно .. понятно, что ни понятие RC ни версионика вы не осилили. да, и поверьте каша получаемая в одном запросе и "увидеть изменения, сделаные в других транзакциях" несколько разные явления ...
29 ноя 08, 00:44    [6503215]     Ответить | Цитировать Сообщить модератору
 Re: Firebird vs Postgres  [new]
kdv
Member

Откуда: iBase.ru
Сообщений: 30285
Yo
да, и поверьте каша получаемая в одном запросе и "увидеть изменения, сделаные в других транзакциях" несколько разные явления ...

мое мнение по этому поводу - rc это read committed. т.е. неповторяющееся чтение. Поэтому, стабильность курсора в этом режиме абсолютно пофиг.
Вернее даже так. Почему повторяющиеся в RC запросы могут видеть данные, а отдельный запрос в RC должен выполняться в режиме snapshot? Ведь под "стабильностью курсора в RC" имеется в виду как раз именно это - читай данные committed с момента старта запроса, и не моги видеть committed данные возникшие во время работы запроса (пусть это будут фантомы).
Мне ближе разумный пессимизм, чем непонятно на чем основанный оптимизм. Даже если "так говорит стандарт".
29 ноя 08, 08:01    [6503400]     Ответить | Цитировать Сообщить модератору
 Re: Firebird vs Postgres  [new]
Senya_L
Member

Откуда: Москва
Сообщений: 5381
Yo.!
Senya_L

Я так и понял, чем нормальный, "рабочий" read comimted в Firebird вам не угоден? И вообще это похоже на религиозный бред.

а это лишь от того, что вы не поняли даже о чем собственно я толкую. в прочем как и со стабильностью курсора
Да отлично я понимаю, о чем вы толкуете. Вы повторяетесь уже в сотый раз в тридесятом топике Про стабильность курсора, про выражения DELETE FROM ... WHERE ... . Читал я ваши высказывания. Не верю (С) Станиславский :)
Yo.!
Senya_L

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

угу, предельно понятно .. понятно, что ни понятие RC ни версионика вы не осилили. да, и поверьте каша получаемая в одном запросе и "увидеть изменения, сделаные в других транзакциях" несколько разные явления ...
А чего тут понимать? Вы предельно четко высказали недовольство, по поводу реализации Read Commited в Firebird:
Yo.!
как раз у версионика нормальный READ COMMITED, который при чтении вернет консистентный набор данных на момент старта запроса.
Вы говорите тезисами и непонятно, с чего это "нормальный" версионник должен (Вам лично, что ли?) поступать именно так. Меня устраивает этот уровень изоляции для определенных целей. Если мне требуется "консистентный" набор, то я воспользуюсь SNAPSHOT.
29 ноя 08, 11:28    [6503503]     Ответить | Цитировать Сообщить модератору
 Re: Firebird vs Postgres  [new]
Yo.!
Guest
2kdv

формально да, тут ФБ совершенно не противоречит RC, но в реальной жизни чтоб жить с этой кашей в наборе нужно гораздо более квалифицированное проэктирование, очень окуратное кодирование и недюжуя изобретательность, чтоб не влипнуть. имхо нормальный snapshot/RC_snapshot настолько упрощает жизнь, что полезность такого "блокировочного RC" становится сильно меньшая.
а со стабильностью курсора - так, что в 2.5 что-то изменится ?

2Senya_L

неа, не понимаете. delete from всего лишь один из случаев огромного кол-ва вариантов неправильного поведения.
29 ноя 08, 12:27    [6503567]     Ответить | Цитировать Сообщить модератору
 Re: Firebird vs Postgres  [new]
Dimitry Sibiryakov
Member

Откуда:
Сообщений: 54840

Yo.!

а со стабильностью курсора - так, что в 2.5 что-то изменится ?

А нафига? Всех недовольных мы просто посылаем на Оракул или (по просьбе
softwarer-а) - на MSSQL. Пусть мучают тамошних апологетов. Пойми
ты: у Firebird нет рынка. От разгона пары сотен недовольных
убытков не будет. Те, от кого можно получить деньги, недовольны совсем
другими вещами, которые и будут в 2.5-3.0.

Posted via ActualForum NNTP Server 1.4

29 ноя 08, 13:01    [6503623]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 [2] 3 4 5   вперед  Ctrl      все
Все форумы / Сравнение СУБД Ответить