Этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
Политика конфиденциальности
|
|
|
Интересный и важный момент обновления записи (помогите)
|
|||
|---|---|---|---|
|
#18+
Здравствуйте. Помогите, пожалуйста, понять причину следующей особенности. Есть таблица: Код: plsql 1. 2. 3. 4. 5. 6. Заполненная случайными значениями: Код: plsql 1. Есть "счетчик": Код: plsql 1. 2. 3. 4. 5. 6. 7. 8. Если добавлять значения случайным записям, мой компьютер отрабатывает в среднем за 3.0 сек. Код: plsql 1. Если обновлять значение определенной записи - за 22.5 (!) сек. Код: plsql 1. В чем дело? Где загвоздка? И следом второй вопрос. Если нужно большое количество независимых последовательностей (sequence), правильно ли ее реализовывать приведенным выше способом в одной таблице? Или блокировки будут сильно мешать, и лучше забыть на неудобство и реализовать их управление процедурно (присутствует логика управления и периодичность обнуления)? -- "PostgreSQL 9.5.3, compiled by Visual C++ build 1600, 32-bit" ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.09.2016, 08:22 |
|
||
|
Интересный и важный момент обновления записи (помогите)
|
|||
|---|---|---|---|
|
#18+
VladimirDmitriev, Тормоза с обновлением единственной записи связаны с реализацией MVCC в PostgreSQL. К слову сказать, совершенно непонятно, зачем вы так делаете. С последовательностями неправильно, для корректной реализации их вам потребуются автономные транзакции или особое умение клиента работать с ними. К слову сказать, а чем не устраивают штатные последовательности? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.09.2016, 11:15 |
|
||
|
Интересный и важный момент обновления записи (помогите)
|
|||
|---|---|---|---|
|
#18+
Author the new oneVladimirDmitriev, Тормоза с обновлением единственной записи связаны с реализацией MVCC в PostgreSQL. К слову сказать, совершенно непонятно, зачем вы так делаете. С последовательностями неправильно, для корректной реализации их вам потребуются автономные транзакции или особое умение клиента работать с ними. К слову сказать, а чем не устраивают штатные последовательности? Думаю, это надо для безразрывной нумерации записей. Знаменитейший антипаттерн ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.09.2016, 11:29 |
|
||
|
Интересный и важный момент обновления записи (помогите)
|
|||
|---|---|---|---|
|
#18+
Author the new oneVladimirDmitriev, Тормоза с обновлением единственной записи связаны с реализацией MVCC в PostgreSQL. Спасибо. Можете пояснить немного подробнее? Хочется полного понимания. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.09.2016, 11:34 |
|
||
|
Интересный и важный момент обновления записи (помогите)
|
|||
|---|---|---|---|
|
#18+
ОКТОГЕН, Вы правы. "Присутствует логика управления и периодичность обнуления". ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.09.2016, 11:39 |
|
||
|
Интересный и важный момент обновления записи (помогите)
|
|||
|---|---|---|---|
|
#18+
ОКТОГЕН, Вы правы. "Присутствует логика управления и периодичность обнуления". ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.09.2016, 11:40 |
|
||
|
Интересный и важный момент обновления записи (помогите)
|
|||
|---|---|---|---|
|
#18+
VladimirDmitrievОКТОГЕН, Вы правы. "Присутствует логика управления и периодичность обнуления". Как вы собираетесь поддерживать актуальные номера во всех других ссылках и внутри всех документах? Да ещё при конкурентном доступе? Зачем вам этот нереальный геморрой? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.09.2016, 11:58 |
|
||
|
Интересный и важный момент обновления записи (помогите)
|
|||
|---|---|---|---|
|
#18+
ОКТОГЕН, Геморрой не мой. Как раз хочу излечить. Спасибо. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.09.2016, 14:46 |
|
||
|
Интересный и важный момент обновления записи (помогите)
|
|||
|---|---|---|---|
|
#18+
VladimirDmitrievЕсть таблица: Код: plsql 1. 2. 3. 4. 5. 6. А почему numeric-и, а не int-ы, например? Я начну со второго вопроса: VladimirDmitrievЕсли нужно большое количество независимых последовательностей (sequence), правильно ли ее реализовывать приведенным выше способом в одной таблице? Да, правильно. Кстати, [вены] правильно резать вдоль. ;) Это я к тому, что с неразрывными последовательностями (gapless sequence) стоит связываться только тогда, когда этого требует какой-нибудь закон, да и тогда их обычно нужно одна-две, и используются они обычно для номеров каких-нибудь документов. VladimirDmitrievИли блокировки будут сильно мешать, и лучше забыть на неудобство и реализовать их управление процедурно (присутствует логика управления и периодичность обнуления)? Скорее всего, будут мешать, и с этим ничего не поделаешь --- для неразрывной последовательности необходима "точка сериализации". И, более того, т.к. полученное значение должно быть использовано в той же транзакции, то все прочие, которым нужно значение этой последовательности, ждут её завершения. Поэтому общая производительность будет в основном зависеть не от того, насколько быстро генерируются эти значения, а от длительности конкурирующих транзакций. VladimirDmitrievЕсли добавлять значения случайным записям, мой компьютер отрабатывает в среднем за 3.0 сек. Код: plsql 1. Если обновлять значение определенной записи - за 22.5 (!) сек. Код: plsql 1. В чем дело? Где загвоздка? Загвоздка в том, что если Вы таким образом пытаетесь получить ответ на второй вопрос, Вы измеряете погоду на Марсе. ;) Во-первых, см. выше, во-вторых, Вы же не собираетесь использовать это таким образом (т.е. получать 30000 номеров в одной транзакции), зачем Вы это измеряете? Если уж измерять, то как-то так (создаёте файлы с тестируемыми запросами, используете их в pgbench): Код: sql 1. 2. 3. 4. 5. 6. 7. 8. И вот у меня, например, получается: Код: sql 1. 2. Хотя смысла в этом я (косвенно замерив, в основном, продолжительность COMMIT-а), опять-таки, не вижу. ;) Если же Вас всё ещё интересует ответ на первый вопрос, то см.: https://www.postgresql.org/docs/current/static/storage.html и src/backend/access/heap/README.HOT в исходниках. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.10.2016, 14:00 |
|
||
|
|

start [/forum/topic.php?fid=53&msg=39318307&tid=1996972]: |
0ms |
get settings: |
9ms |
get forum list: |
13ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
175ms |
get topic data: |
11ms |
get forum data: |
2ms |
get page messages: |
51ms |
get tp. blocked users: |
1ms |
| others: | 15ms |
| total: | 283ms |

| 0 / 0 |
