Этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
Политика конфиденциальности
|
|
|
Ускорить работу INSERT (faq читан)
|
|||
|---|---|---|---|
|
#18+
Добрый день! Нужно вставить в таблицу более миллиона строк, с ростом количества postgre начинает все более и более медленно работать, почему? Если бы скорость не падал, то было бы и ничего. COPY не катит, нужно вставлять данные связанные с другими таблицами и есть поле serial. Индексов нет. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.04.2005, 14:47 |
|
||
|
Ускорить работу INSERT (faq читан)
|
|||
|---|---|---|---|
|
#18+
Vasily_s нужно вставлять данные связанные с другими таблицами и есть поле serial ну, сериал вряд ли тормозит. А вот вторичные ключи и чеки могут. Можете в начале транзакции снести чеки и форейгн кеи, а в конце создать правила (чеки и фк) наново (и даже предварительно провернуть удаление "неправильных" (не соответствующих чекам и ф.к.) строк). Но, боюсь, это может потребовать ровно столько же времени (надо пробовать). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.04.2005, 15:04 |
|
||
|
Ускорить работу INSERT (faq читан)
|
|||
|---|---|---|---|
|
#18+
vacuum analuze делай перед пачкой Insert'ов ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.04.2005, 15:39 |
|
||
|
Ускорить работу INSERT (faq читан)
|
|||
|---|---|---|---|
|
#18+
4321 Vasily_s нужно вставлять данные связанные с другими таблицами и есть поле serial ну, сериал вряд ли тормозит. А вот вторичные ключи и чеки могут. Можете в начале транзакции снести чеки и форейгн кеи, а в конце создать правила (чеки и фк) наново (и даже предварительно провернуть удаление "неправильных" (не соответствующих чекам и ф.к.) строк). Но, боюсь, это может потребовать ровно столько же времени (надо пробовать). Хм, вставка происходит в пустую базу/таблицу, т.е. сразу после установки Postgree, да, версия 7.4.7. wbearvacuum analuze делай перед пачкой Insert'ов Они по одному идут, без всяких замудрений, при направлении в ноль, софтина отрабатывает шустро. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.04.2005, 15:47 |
|
||
|
Ускорить работу INSERT (faq читан)
|
|||
|---|---|---|---|
|
#18+
при миллионе, я бы временно загрузил сначала напрямую затем insert into NunaTable select * from NenunaTable и так по всей иерархии связанных таблиц ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.04.2005, 08:51 |
|
||
|
Ускорить работу INSERT (faq читан)
|
|||
|---|---|---|---|
|
#18+
roottimпри миллионе, я бы временно загрузил сначала напрямую затем insert into NunaTable select * from NenunaTable и так по всей иерархии связанных таблиц Это все понятно, но это кусок хороший переписывать. Вопрос немного в другом, ПОЧЕМУ с ростом базы INSERT работает все медленнее и медленнее?????????? Если бы скорость не падала, то и проблем бы не было. А так более 5 раз замедление и прогрессирует! ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.04.2005, 08:35 |
|
||
|
Ускорить работу INSERT (faq читан)
|
|||
|---|---|---|---|
|
#18+
Vasily_s Вопрос немного в другом, ПОЧЕМУ с ростом базы INSERT работает все медленнее и медленнее?????????? Если бы скорость не падала, то и проблем бы не было. А так более 5 раз замедление и прогрессирует! А вставки делаются в одну таблицу или в несколько связанных? Замедление, кроме того, может происходить в случае, если выполняется CHECKPOINT. После того, как он закончит выполняться, всё снова будет быстро... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.04.2005, 10:24 |
|
||
|
Ускорить работу INSERT (faq читан)
|
|||
|---|---|---|---|
|
#18+
Sad Spirit Vasily_s Вопрос немного в другом, ПОЧЕМУ с ростом базы INSERT работает все медленнее и медленнее?????????? Если бы скорость не падала, то и проблем бы не было. А так более 5 раз замедление и прогрессирует! А вставки делаются в одну таблицу или в несколько связанных? Замедление, кроме того, может происходить в случае, если выполняется CHECKPOINT. После того, как он закончит выполняться, всё снова будет быстро... в одну, более 95-97% простые инсерты, есть немного инсертов со связями. так, нормально не становится, чем дальше, тем хуже :( Тут собственно я грешу на размеры файлов базы, можно ли как задать их размер менее чем 1Gb по умолчанию. Блин, неужели на больших размерах ни у кого не тормозят инсерты на базах более нескольких миллионов записей??? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.04.2005, 11:05 |
|
||
|
Ускорить работу INSERT (faq читан)
|
|||
|---|---|---|---|
|
#18+
Возможно из-за особенностей работы файловой структуры. Если таблица большая (а она хранится в системе в виде файла с именем OID), то влияет дефрагментация файла и прочие фишки для файлов большой длины. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.04.2005, 21:06 |
|
||
|
Ускорить работу INSERT (faq читан)
|
|||
|---|---|---|---|
|
#18+
Crocoто влияет дефрагментация файла и прочие фишки для файлов большой длины. На Линуксе дефрагментация отсутствует. Или у вас есть предложения? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.04.2005, 00:55 |
|
||
|
Ускорить работу INSERT (faq читан)
|
|||
|---|---|---|---|
|
#18+
Хм, вставка происходит в пустую базу/таблицу, т.е. сразу после установки исходя вот из этого заявления: во-первых это таблиц(у/ы) нужно создать без constraints, без check, и без индексов. (если непонятно, это также означает и без первичного ключа) во-вторых надо обязательно использовать COPY и наче никак. в-третьих можно увеличить значения checkpoint_segments, wal_buffers дальше, когда будут создаваться индексы и ключи, имеет смысл задрать maintenance_work_mem, если конечно это не слишком занятая машина ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.04.2005, 15:58 |
|
||
|
Ускорить работу INSERT (faq читан)
|
|||
|---|---|---|---|
|
#18+
избавься от вторичных ключей по возможности разумееца ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.04.2005, 13:12 |
|
||
|
Ускорить работу INSERT (faq читан)
|
|||
|---|---|---|---|
|
#18+
nekoво-первых это таблиц(у/ы) нужно создать без constraints, без check, и без индексов. (если непонятно, это также означает и без первичного ключа) во-вторых надо обязательно использовать COPY и наче никак. в-третьих можно увеличить значения checkpoint_segments, wal_buffers И еще можно fsync=off. Сам не экспериментировал, хотя скоро может встать потребность (~100000 строк возможно единовременно и желательно без больших задержек, т.к. реал-тайм). Моё глубокое убеждение, что тормозит логгирование. Кроме того, попробовал как-то раз триггер повесить на суммирование поля в другой таблице, так он для каждой строчки, вставляемой в target таблицу, вставлял в sum таблицу, а потом её ещё раз переписывал и т.д. Версионник это хорошо, но если б он на винт сбрасывал только конечные версии, было бы совсем замечательно. Тогда я написал систему триггеров на perl, которая суммировала это дело, а потом сбрасывало в sum таблицу. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.04.2005, 10:58 |
|
||
|
Ускорить работу INSERT (faq читан)
|
|||
|---|---|---|---|
|
#18+
Funny_Falcon И еще можно fsync=off. Сам не экспериментировал, хотя скоро может встать потребность (~100000 строк возможно единовременно и желательно без больших задержек, т.к. реал-тайм). Моё глубокое убеждение, что тормозит логгирование. нет, fsync можно не трогать, при условии что используется COPY поскольку fsync делается только при коммите, а COPY целиком попадает в одну транзакцию ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.04.2005, 05:02 |
|
||
|
Ускорить работу INSERT (faq читан)
|
|||
|---|---|---|---|
|
#18+
А проблема тем не менее прогресирующаяя. может таки нельзя много пихать в постгрес? тогда, а куда можно? :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.04.2005, 20:16 |
|
||
|
Ускорить работу INSERT (faq читан)
|
|||
|---|---|---|---|
|
#18+
Следил я следил за топиком решил вот вместо рассуждений сделать маленький тестик суть теста сделать поочереди несколько измерений времени при INSERTе в PG записей (правда 8.0 у меня может поэтому и рез такие. Хотя большие сомнения у меня что они ядро настолько переписали) 10 000 100 000 500 000 1000 000 потом снова 10 000 100 000 500 000 (дальше не стал - место на винте кончилось да и ждать долго а ночью комп спать мешает) Комп обычный домашний - Celeron 1.7 ГГц - памяти 512 - винт какойто IBM если мне память не изменяет - база PostgreSQL 8.0.0 установка по дефолту (те ничего не настраивал поставил и все) - ОС WindowsXP (дефрагментация не делалась никогда ОС стоит около года причем на диске где стоит Postgre и где находится tablespace всевремя чего нить записывают а потом стирают например кино) - клиент Java 1.4 - DDL таблицы Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. код на java Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. как видим операция выполняется с помощью так называемого биндинга (PrepareStatement) и результаты (все последовательно добавляется в одну таблицу) 10 000 - 34 сек 100 000 - 322 сек 500 000 - 1473 сек 1000 000 - 3233 сек потом опять 10 000 - 33 сек 100 000 - 312 сек 500 000 - 1522 сек замерял наручным секундомером ( вот я лох надо было в проге считать ) но думаю картина бы не изменилась ... что же мы увидели ... линейную зависимость при вставке данных те не важно 100, 1000, 10 000 или 1000 000 вставляем зависимость линейная (хотя опять повторьсь постгрес 8.0) Вопрос тогда людям у которых проблемы на чем клиент к базе писан и каким образом идет INSERT??? как у меня биндинг или просто стрингами??? Кстати недавно читал в какойто книжке чтото типа: Хотите поставить на колени ЛЮБУЮ базу??? НЕ используйте биндинг! про оракл кажись книженка ------------------------------ жизнь как пестня ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.04.2005, 00:18 |
|
||
|
Ускорить работу INSERT (faq читан)
|
|||
|---|---|---|---|
|
#18+
А если открывать сессию (здесь это dbCon) на каждую запись. т.е. не открыли сессию вдули 10000 строк закрыли, а открывать делать запись и закрывать. Дело втом что источников данных может быть много.. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.04.2005, 12:36 |
|
||
|
Ускорить работу INSERT (faq читан)
|
|||
|---|---|---|---|
|
#18+
Алексей Ключников ... открывать делать запись и закрывать. Дело втом что источников данных может быть много.. ну и что что много зачем сессию то менять? открыл коннект к базе а потом с ним работай хоть из 100 источников пиши! если делать как вы написали (да еще стринги (INSERT) в базу лить) то никаких ресурсов на 1000000 строк не хватит!!! (если хотите чтото напечатать в ворде из 10 разных книжек тоже 10 раз будете его закрывать и открывать???) биндинг насколько я знаю есть точно в перле, на сях и в яве. пхп, питон и чего нить еще смотреть надо (с другими не работал). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.04.2005, 12:50 |
|
||
|
Ускорить работу INSERT (faq читан)
|
|||
|---|---|---|---|
|
#18+
Про биндинг надо у програмера спросить :) А если источники разные то как на них открыть одну сессию. Или это тоже к программеру.. Тут еще вопрос надежности, одна сессия может, в следствии потери связи, оборваться. и что тогда? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.04.2005, 13:02 |
|
||
|
Ускорить работу INSERT (faq читан)
|
|||
|---|---|---|---|
|
#18+
Пишем на сях через библиотечку pglib.so кажется так завется. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.04.2005, 13:06 |
|
||
|
Ускорить работу INSERT (faq читан)
|
|||
|---|---|---|---|
|
#18+
Алексей КлючниковА если источники разные то как на них открыть одну сессию. открыть соединение с БД (1 сессия) первый источник (данные) запись второй источник (данные) запись и тд закрыть соединение с БД ну я так себе представляю это. Те БД пополам откуда ты в нее пишеш лишь бы все правильно с ее точки зрения было (порядок там типы всякие) Тут еще вопрос надежности, одна сессия может, в следствии потери связи, оборваться. и что тогда? если потеряли связь с БД то у тебя все сессии отвалятся ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.04.2005, 13:19 |
|
||
|
Ускорить работу INSERT (faq читан)
|
|||
|---|---|---|---|
|
#18+
А commit делать не пробовали? Например каждую 2000-ю запись? Иногда помагает. Иначе Вы в процессе вставки просто немеряно раздуваете сегмент отката (или что там у PG). Естессна ему нехорошо. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.04.2005, 17:57 |
|
||
|
Ускорить работу INSERT (faq читан)
|
|||
|---|---|---|---|
|
#18+
вообще надо читать про библиотеки как они там с commit работают мож если не указанно явно то они его автоматом лепят а вообще если BEGIN TRANSACTION нет то по идее и commit не нужен ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.04.2005, 18:16 |
|
||
|
Ускорить работу INSERT (faq читан)
|
|||
|---|---|---|---|
|
#18+
vfabrвообще надо читать про библиотеки как они там с commit работают мож если не указанно явно то они его автоматом лепят а вообще если BEGIN TRANSACTION нет то по идее и commit не нужен Как это не нужен? Щас прийдут FB-шники и станут размахивать серпами. Я не местный, поэтому не знаю насколько кретична для PG длинная транзакция со вставками, но абсолютно уверен в том, что ему будет существенно легче если Вы будете подтверждать вставки пачками. На www.ibase.ru есть очень хорошая статья на эту тему. ЗЫ: насколько я понимаю, подтверждение каждой записи тоже может быть чревато. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.04.2005, 18:31 |
|
||
|
Ускорить работу INSERT (faq читан)
|
|||
|---|---|---|---|
|
#18+
документация PGIn PostgreSQL, a transaction is set up by surrounding the SQL commands of the transaction with BEGIN and COMMIT commands. So our banking transaction would actually look like Код: plaintext 1. 2. 3. 4. PostgreSQL actually treats every SQL statement as being executed within a transaction. If you do not issue a BEGIN command, then each individual statement has an implicit BEGIN and (if successful) COMMIT wrapped around it. A group of statements surrounded by BEGIN and COMMIT is sometimes called a transaction block. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.04.2005, 19:41 |
|
||
|
Ускорить работу INSERT (faq читан)
|
|||
|---|---|---|---|
|
#18+
v fabr документация PG... Гы. А полную версию можно? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.04.2005, 21:07 |
|
||
|
Ускорить работу INSERT (faq читан)
|
|||
|---|---|---|---|
|
#18+
http://www.postgresql.org/docs/8.0/interactive/tutorial-transactions.html где ж еще ;-))) --------------------------- жизнь как пестня ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.04.2005, 22:11 |
|
||
|
Ускорить работу INSERT (faq читан)
|
|||
|---|---|---|---|
|
#18+
vfabrhttp://www.postgresql.org/docs/8.0/interactive/tutorial-transactions.html где ж еще ;-))) --------------------------- жизнь как пестня Понятно что здесь. Кстати, ту же доку можно найти в каталоге PG. Непонятно только зачем вы представили публике вырезку про транзакции. Там написано всего лишь, что запросы можно оформлять в блоки и подтверждать/откатывать не один запрос, а несколько. Еще там написано, что каждый запрос является по сути блоком. Иначе говоря, при появлении ошибки в запросе, обрабатывающем несколько строк откатывается обработка всех строк. Короче, ничего нового. ЗЫ: здается мне, что драйвер, который Вы используете не умеет работать с параметрами. По коду очень похоже на то, что он просто подставляет значения строк в запрос, делая предварительно Escape. Если так, то запрос на вставку будет парситься сервером каждый раз заново. Гыыыы. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.04.2005, 22:38 |
|
||
|
Ускорить работу INSERT (faq читан)
|
|||
|---|---|---|---|
|
#18+
авторПонятно что здесь. Кстати, ту же доку можно найти в каталоге PG. не туже на сайте есть вещи которые в доке не описаны авторНепонятно только зачем вы представили публике вырезку про транзакции. Там написано всего лишь, что запросы можно оформлять в блоки и подтверждать/откатывать не один запрос, а несколько. Еще там написано, что каждый запрос является по сути блоком . вот именно блоком! а привел не всем а вам потому что вы начали советовать COMMIT ... авторздается мне, что драйвер, который Вы используете не умеет работать с параметрами. По коду очень похоже на то, что он просто подставляет значения строк в запрос, делая предварительно Escape. Если так, то запрос на вставку будет парситься сервером каждый раз заново. Гыыыы. мужчина проблема с инсертами была не у меня (у меня как раз ничего не тормозит поэтому меня эта ситуация и удивляет) я вместо рассуждений сделал тест который дал результаты если они вас чемто не устраивают буду благодарен за конструктивную критику. мой драйвер делает все что нужно (и символы эскейпит тоже) и как раз анализатору скармливаются только параметры а используется подготовленный запрос и посылается он 1 раз в самом начале так что тут все нормально (зачем по вашему конструкция st.setString("") и st.setInt(int) ???) и еще не надо нас тут файрбердом пугать и как придут так и уйдут FB как вы выразились ;-)) PS я еще год назад выбирал между FB и PostgrSQL выбор сделан! PG и ничуть не жалею (еслиб я на дельфи писал (восхищенно) ... а так бедная никому не нужная ява :'-(( (рыдает) ) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.04.2005, 23:00 |
|
||
|
Ускорить работу INSERT (faq читан)
|
|||
|---|---|---|---|
|
#18+
ребят тут речь шла о заполнение чистой базы видимо upgrade сервера или установка какого-нибудь приложения а вы сюда потерю соединения приплепи если у кого-то теряется соединение с localhost, тут проблемы посерьезнее... и делать это надо через COPY, это самое важное при загрузки большого количества данных ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.04.2005, 00:14 |
|
||
|
Ускорить работу INSERT (faq читан)
|
|||
|---|---|---|---|
|
#18+
тоесть надо из одной базы (например) все прочитать и записать в файлик а потом сделать copy? так чтоли? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.04.2005, 00:26 |
|
||
|
Ускорить работу INSERT (faq читан)
|
|||
|---|---|---|---|
|
#18+
Не я начал топик, но проблема сходная. nekoребят тут речь шла о заполнение чистой базы видимо upgrade сервера или установка какого-нибудь приложения а вы сюда потерю соединения приплепи если у кого-то теряется соединение с localhost, тут проблемы посерьезнее... Не upgrade а куча датчиков крунлоситочно валящих данные. и на с лосал хост а с разных хостов и от разных процессов на этих хостах. по этому и есть проблема обрыва сессиии и хотелось бы при этом поменьше данных терять. А проблема все таки в том что в большую таблицу инсерты тормозят. Данные ложаться посредством вызова ХП. потом проходят через пару таблиц и только потом в архив. т.е. инсерты делаются как обычные инсерты на plpgsql. что тут не так? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.04.2005, 11:14 |
|
||
|
Ускорить работу INSERT (faq читан)
|
|||
|---|---|---|---|
|
#18+
а так вы вот про какие сессии ... не всеравно к базе 1 коннект а от датчиков только проблемы с данными (проверять если от датчика пришел null то и не писать в базу ничего) а вот с ХП надо подумать ... plsql это не совсем sql он рядом да не совсем ... ты спроси у программера как я сказал (а еще лучше сделайте тестик если конечно возможность есть) ... напиши как результаты а потом можно будет дальше думать ------------------------------- жизнь как пестня ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.04.2005, 11:21 |
|
||
|
Ускорить работу INSERT (faq читан)
|
|||
|---|---|---|---|
|
#18+
vfabr авторНепонятно только зачем вы представили публике вырезку про транзакции. Там написано всего лишь, что запросы можно оформлять в блоки и подтверждать/откатывать не один запрос, а несколько. Еще там написано, что каждый запрос является по сути блоком . вот именно блоком! а привел не всем а вам потому что вы начали советовать COMMIT ... Кто - то из нас двоих тупит. Блок - по сути вложенная транзакция. Она коммитится в рамках внешней. А внешняя при этом остается неподтвержденной (если конечно не используется что - то типа автокоммита). Я не юзал драйвер, который вы указали, поэтому не вполне уверен в том как он коммитит изменения, но то, что при множественной вставке коммиты необходимо оптимизировать отдельно - факт. Причем это актуально для SQL - сервера любого типа (для тех, кто в танке повторюсь - коммит каждой записи тоже не есть гуд). vfabr авторздается мне, что драйвер, который Вы используете не умеет работать с параметрами...мужчина проблема с инсертами была не у меня (у меня как раз ничего не тормозит... ... используется подготовленный запрос и посылается он 1 раз в самом начале так что тут все нормально (зачем по вашему конструкция st.setString("") и st.setInt(int) ???)Говорить можно долго. Я могу и ошибаться. Рассудить нас может только SQL-монитор. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.04.2005, 14:51 |
|
||
|
Ускорить работу INSERT (faq читан)
|
|||
|---|---|---|---|
|
#18+
ozБлок - по сути вложенная транзакция. кхм. по моим ощущениям никаких вложенных транзакций в постгрессе нет (т.е. не было в 7.ххх. из за чего, кстати, в нем куча траблов с руле и т.п.). В 8-м появилось что-то типа точек возврата (но это - внутри _одной транзакции_). Но не смотрел - врать не буду. Если я ошибаюсь - поправьте. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.04.2005, 16:23 |
|
||
|
Ускорить работу INSERT (faq читан)
|
|||
|---|---|---|---|
|
#18+
2oz http://www.postgresql.org/docs/8.0/interactive/sql-begin.html сходите и почитайте про транзакции (тупит кто-то 100% ;-) ) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.04.2005, 20:14 |
|
||
|
Ускорить работу INSERT (faq читан)
|
|||
|---|---|---|---|
|
#18+
oz(для тех, кто в танке повторюсь - коммит каждой записи тоже не есть гуд проблема была не в том чтобы ускорить инсерт, а в том чтобы доказать что с ростом таблицы при больших инсертах ничего не тормозит (те по болту что 10 записей вставлять что 1000000 зависимость линейная!!!) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.04.2005, 20:36 |
|
||
|
Ускорить работу INSERT (faq читан)
|
|||
|---|---|---|---|
|
#18+
To vfabr провел тест. правда визуально смотрел на бегущие инсерты, через часа три бегут значительно медленне :) Не могли бы вы повторить свой тест обвязав таблицу индексами, о двум трем полям. P.S. А hesh индекс термоядрен. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.04.2005, 20:18 |
|
||
|
Ускорить работу INSERT (faq читан)
|
|||
|---|---|---|---|
|
#18+
приведи код с клиента на котором тестил (неважно какой язык) полностью еще лучше будет (файлик приложи например) и DDL таблицы со всеми индексами и прочей фигней а то так тестить безтолку ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.04.2005, 20:35 |
|
||
|
Ускорить работу INSERT (faq читан)
|
|||
|---|---|---|---|
|
#18+
Прога Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. Фнкция dev.put_data Код: plaintext 1. 2. 3. 4. 5. 6. 7. Далее срабатывает триггер, данные обрабатываются.. И функция инсерт данных в архив, вызываемая триггером Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.04.2005, 12:25 |
|
||
|
Ускорить работу INSERT (faq читан)
|
|||
|---|---|---|---|
|
#18+
аг постараюсь побыстрее ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.04.2005, 12:46 |
|
||
|
Ускорить работу INSERT (faq читан)
|
|||
|---|---|---|---|
|
#18+
2 Алексей Ключников: Приведите еще плиз структуру таблицы dev.current_data (конечно с индексами,..). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.04.2005, 13:03 |
|
||
|
Ускорить работу INSERT (faq читан)
|
|||
|---|---|---|---|
|
#18+
Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. Таблица представляет собой срез текущих данных. т.е. содержит 200 строк в которые производиться только update, IHMO от индексов здесь не мого зависит. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.04.2005, 13:13 |
|
||
|
Ускорить работу INSERT (faq читан)
|
|||
|---|---|---|---|
|
#18+
для апдейтов наблюдается замедление select version(); version --------------------------------------------------------------------------------------------------------- PostgreSQL 7.3.3 on i686-pc-linux-gnu, compiled by GCC gcc (GCC) 3.2.2 20030222 (Red Hat Linux 3.2.2-5) (1 row) CREATE TABLE temp1 ( id int4 NOT NULL, data1 float8, data2 float8, data3 float8, data4 float8, data5 float8, error int4, status int4, mode_id int4, datatime timestamp ); CREATE INDEX temp1_id ON temp1 USING btree (id); insert into temp1 values ( 1 ); insert into temp1 select id+2^0 from temp1; insert into temp1 select id+2^1 from temp1; insert into temp1 select id+2^2 from temp1; insert into temp1 select id+2^3 from temp1; insert into temp1 select id+2^4 from temp1; insert into temp1 select id+2^5 from temp1; insert into temp1 select id+2^6 from temp1; insert into temp1 select id+2^7 from temp1; +++ $ time perl -e 'printf "begin;\n"; for (my $i=1; $i<=1000; $i++) { printf "update temp1 set datatime = now(), error = %d, data1 = %f, mode_id = %d, status = %d where id = %d;\n", rand(10), rand(10), rand(), rand(1000), 1+rand(256); } printf "commit;\n";' | psql >/dev/null real 0m1.824s user 0m0.290s sys 0m0.070s $ time perl -e 'printf "begin;\n"; for (my $i=1; $i<=10000; $i++) { printf "update temp1 set datatime = now(), error = %d, data1 = %f, mode_id = %d, status = %d where id = %d;\n", rand(10), rand(10), rand(), rand(1000), 1+rand(256); } printf "commit;\n";' | psql >/dev/null real 0m18.317s user 0m1.970s sys 0m0.710s $ time perl -e 'printf "begin;\n"; for (my $i=1; $i<=100000; $i++) { printf "update temp1 set datatime = now(), error = %d, data1 = %f, mode_id = %d, status = %d where id = %d;\n", rand(10), rand(10), rand(), rand(1000), 1+rand(256); } printf "commit;\n";' | psql >/dev/null real 4m59.599s user 0m20.010s sys 0m6.200s $ time perl -e 'printf "begin;\n"; for (my $i=1; $i<=1000; $i++) { printf "update temp1 set datatime = now(), error = %d, data1 = %f, mode_id = %d, status = %d where id = %d;\n", rand(10), rand(10), rand(), rand(1000), 1+rand(256); } printf "commit;\n";' | psql >/dev/null real 0m3.541s user 0m0.260s sys 0m0.070s $ time perl -e 'printf "begin;\n"; for (my $i=1; $i<=10000; $i++) { printf "update temp1 set datatime = now(), error = %d, data1 = %f, mode_id = %d, status = %d where id = %d;\n", rand(10), rand(10), rand(), rand(1000), 1+rand(256); } printf "commit;\n";' | psql >/dev/null real 0m21.036s user 0m2.020s sys 0m0.670s $ time perl -e 'printf "begin;\n"; for (my $i=1; $i<=100000; $i++) { printf "update temp1 set datatime = now(), error = %d, data1 = %f, mode_id = %d, status = %d where id = %d;\n", rand(10), rand(10), rand(), rand(1000), 1+rand(256); } printf "commit;\n";' | psql >/dev/null real 5m32.434s user 0m19.560s sys 0m6.620s $ time perl -e 'printf "begin;\n"; for (my $i=1; $i<=1000; $i++) { printf "update temp1 set datatime = now(), error = %d, data1 = %f, mode_id = %d, status = %d where id = %d;\n", rand(10), rand(10), rand(), rand(1000), 1+rand(256); } printf "commit;\n";' | psql >/dev/null real 0m3.114s user 0m0.160s sys 0m0.090s $ time perl -e 'printf "begin;\n"; for (my $i=1; $i<=10000; $i++) { printf "update temp1 set datatime = now(), error = %d, data1 = %f, mode_id = %d, status = %d where id = %d;\n", rand(10), rand(10), rand(), rand(1000), 1+rand(256); } printf "commit;\n";' | psql >/dev/null real 0m24.179s user 0m2.040s sys 0m0.630s $ time perl -e 'printf "begin;\n"; for (my $i=1; $i<=100000; $i++) { printf "update temp1 set datatime = now(), error = %d, data1 = %f, mode_id = %d, status = %d where id = %d;\n", rand(10), rand(10), rand(), rand(1000), 1+rand(256); } printf "commit;\n";' | psql >/dev/null real 6m5.858s user 0m20.600s sys 0m6.120s $ time perl -e 'printf "begin;\n"; for (my $i=1; $i<=1000; $i++) { printf "update temp1 set datatime = now(), error = %d, data1 = %f, mode_id = %d, status = %d where id = %d;\n", rand(10), rand(10), rand(), rand(1000), 1+rand(256); } printf "commit;\n";' | psql >/dev/null real 0m3.574s user 0m0.280s sys 0m0.100s $ time perl -e 'printf "begin;\n"; for (my $i=1; $i<=10000; $i++) { printf "update temp1 set datatime = now(), error = %d, data1 = %f, mode_id = %d, status = %d where id = %d;\n", rand(10), rand(10), rand(), rand(1000), 1+rand(256); } printf "commit;\n";' | psql >/dev/null real 0m27.060s user 0m1.930s sys 0m0.760s $ time perl -e 'printf "begin;\n"; for (my $i=1; $i<=100000; $i++) { printf "update temp1 set datatime = now(), error = %d, data1 = %f, mode_id = %d, status = %d where id = %d;\n", rand(10), rand(10), rand(), rand(1000), 1+rand(256); } printf "commit;\n";' | psql >/dev/null real 6m38.702s user 0m20.120s sys 0m6.940s $ time perl -e 'printf "begin;\n"; for (my $i=1; $i<=1000; $i++) { printf "update temp1 set datatime = now(), error = %d, data1 = %f, mode_id = %d, status = %d where id = %d;\n", rand(10), rand(10), rand(), rand(1000), 1+rand(256); } printf "commit;\n";' | psql >/dev/null real 0m3.854s user 0m0.260s sys 0m0.030s $ time perl -e 'printf "begin;\n"; for (my $i=1; $i<=10000; $i++) { printf "update temp1 set datatime = now(), error = %d, data1 = %f, mode_id = %d, status = %d where id = %d;\n", rand(10), rand(10), rand(), rand(1000), 1+rand(256); } printf "commit;\n";' | psql >/dev/null real 0m30.249s user 0m1.910s sys 0m0.720s $ time perl -e 'printf "begin;\n"; for (my $i=1; $i<=100000; $i++) { printf "update temp1 set datatime = now(), error = %d, data1 = %f, mode_id = %d, status = %d where id = %d;\n", rand(10), rand(10), rand(), rand(1000), 1+rand(256); } printf "commit;\n";' | psql >/dev/null real 7m7.648s user 0m20.830s sys 0m6.410s $ time perl -e 'printf "begin;\n"; for (my $i=1; $i<=1000; $i++) { printf "update temp1 set datatime = now(), error = %d, data1 = %f, mode_id = %d, status = %d where id = %d;\n", rand(10), rand(10), rand(), rand(1000), 1+rand(256); } printf "commit;\n";' | psql >/dev/null real 0m4.166s user 0m0.320s sys 0m0.100s $ time perl -e 'printf "begin;\n"; for (my $i=1; $i<=10000; $i++) { printf "update temp1 set datatime = now(), error = %d, data1 = %f, mode_id = %d, status = %d where id = %d;\n", rand(10), rand(10), rand(), rand(1000), 1+rand(256); } printf "commit;\n";' | psql >/dev/null real 0m33.677s user 0m2.840s sys 0m0.950s $ time perl -e 'printf "begin;\n"; for (my $i=1; $i<=100000; $i++) { printf "update temp1 set datatime = now(), error = %d, data1 = %f, mode_id = %d, status = %d where id = %d;\n", rand(10), rand(10), rand(), rand(1000), 1+rand(256); } printf "commit;\n";' | psql >/dev/null real 7m42.562s user 0m20.670s sys 0m6.670s $ time perl -e 'printf "begin;\n"; for (my $i=1; $i<=1000; $i++) { printf "update temp1 set datatime = now(), error = %d, data1 = %f, mode_id = %d, status = %d where id = %d;\n", rand(10), rand(10), rand(), rand(1000), 1+rand(256); } printf "commit;\n";' | psql >/dev/null real 0m4.339s user 0m0.250s sys 0m0.090s $ time perl -e 'printf "begin;\n"; for (my $i=1; $i<=10000; $i++) { printf "update temp1 set datatime = now(), error = %d, data1 = %f, mode_id = %d, status = %d where id = %d;\n", rand(10), rand(10), rand(), rand(1000), 1+rand(256); } printf "commit;\n";' | psql >/dev/null real 0m36.375s user 0m1.590s sys 0m0.470s +++ drop table temp1; ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.04.2005, 16:51 |
|
||
|
Ускорить работу INSERT (faq читан)
|
|||
|---|---|---|---|
|
#18+
Весьма показательно. спасибо. тут надо справляться вакумированием. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.04.2005, 17:07 |
|
||
|
Ускорить работу INSERT (faq читан)
|
|||
|---|---|---|---|
|
#18+
Возможно, еще и reindex-ом. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.04.2005, 17:14 |
|
||
|
Ускорить работу INSERT (faq читан)
|
|||
|---|---|---|---|
|
#18+
но есть подозрение что проблема не только в этом т.к. вакум делается 3 раза в сутки. тыт мы видим на 700000 строк уменьшение быстродействия в два раза. а я наблюдаю (субьективно конечно:) на порядок. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.04.2005, 19:00 |
|
||
|
Ускорить работу INSERT (faq читан)
|
|||
|---|---|---|---|
|
#18+
Алексей Ключниковтыт мы видим на 700000 строк уменьшение быстродействия в два раза. а я наблюдаю (субьективно конечно:) на порядок.Но вы писали: "смотрел на бегущие инсерты, через часа три бегут значительно медленне". Сколько строк было обработано в вашем тесте за три часа? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.04.2005, 09:30 |
|
||
|
Ускорить работу INSERT (faq читан)
|
|||
|---|---|---|---|
|
#18+
Напоминаю - PostgreSQL сервер с версионной архитектурой.. в даенном случае судя по коду , идет заливка большого массива данных и на каждый инсерт срабатывает триггер который делает update таблицы dev.current_data Так вот - каждый update - рождает в таблице dev.current_data новую версию записи.. соответвенно при моллионе вставленных записей будет миллион версий записей в dev.current_data, притом при всем что видимых будет как и было около 200... Чем больше версий записей- тем медленней идет поиск даже по индексам...т.к. индекс указывает на первую версию записи ,после чего ищется нужная версия записи путем перебора всех версий.. теперь понятно почему идет замедление? Теперь скажу как бы я избавился от этого.. 1.- Лочим таблицу dev.current_data 2- Делаем массив в памяти - куда переносим все данные из dev.current_data 3- в триггере изменяем не таблицу а этот массив.. 4- сбрасываем массив в dev.current_data ..... Мнения? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.04.2005, 10:34 |
|
||
|
Ускорить работу INSERT (faq читан)
|
|||
|---|---|---|---|
|
#18+
domanixТак вот - каждый update - рождает в таблице dev.current_data новую версию записи.. соответвенно при моллионе вставленных записей будет миллион версий записей в dev.current_data, притом при всем что видимых будет как и было около 200...Такая картина будет после завершения транзакций? domanixиндекс указывает на первую версию записи ,после чего ищется нужная версия записи путем перебора всех версий..Можете кинуть ссылочку на источник этой информации? domanixТеперь скажу как бы я избавился от этого.. 1.- Лочим таблицу dev.current_data 2- Делаем массив в памяти - куда переносим все данные из dev.current_data 3- в триггере изменяем не таблицу а этот массив.. 4- сбрасываем массив в dev.current_data ..... Мнения?pg_autovacuum? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.04.2005, 11:37 |
|
||
|
Ускорить работу INSERT (faq читан)
|
|||
|---|---|---|---|
|
#18+
автор Но вы писали: "смотрел на бегущие инсерты, через часа три бегут значительно медленне". Сколько строк было обработано в вашем тесте за три часа? Беру таймаут на проведение тестов. А вот про апдейты интересно. Действительно где дока? А по задумке данное должно прыгать из таблицы в таблицу минимум 3 раза и только потом в архив.. Похоже плохая задумка :D ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.04.2005, 12:36 |
|
||
|
Ускорить работу INSERT (faq читан)
|
|||
|---|---|---|---|
|
#18+
короче я придумал нужно прыгнуть на ступеньку выше (от техн реализации) 2АК приведи задачу полностью (без существующего решения) откуда поступает инфа и что нужно получить в итоге (и если надо в промежутке) и тогда можно попробовать перестроить схему работы с наименьшими изменениями кстати программера можно подключить :-)) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.04.2005, 12:51 |
|
||
|
Ускорить работу INSERT (faq читан)
|
|||
|---|---|---|---|
|
#18+
domanixв даенном случае судя по коду , идет заливка большого массива данных и на каждый инсерт срабатывает триггер который делает update таблицы dev.current_data а мне кажется из программы идет UPDATE через ХП в табл dev.current_data, а только потом срабатывает триггер на INSERT в arh.base_temp1 domanix Так вот - каждый update - рождает в таблице dev.current_data новую версию записи.. соответвенно при моллионе вставленных записей будет миллион версий записей в dev.current_data, ничего каждый UPDATE не рождает и ничего подобного вроде миллиона версий не будет. Те при простых UPDATE (как впрочем и INSERT зависимость будет линейная). Пробовал просто UPDATE в таблицу с индексами и без оных и все впорядке ничего не тормозит попробую еще через хранимку, а потом на все это дело повешу триггер (делаю так потому что интересно прогнать все блоки отдельно и только потом их соеденить) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.04.2005, 09:55 |
|
||
|
Ускорить работу INSERT (faq читан)
|
|||
|---|---|---|---|
|
#18+
Здача глобальна :) Контроль и управление тех процессом. сбор информации, обработка, показ текущего среза на месте оператора. сохранение в архив. Требуется телать некоторые расчеты, на основе принятых данных и отправлять их исполнительным механизмам. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.04.2005, 10:08 |
|
||
|
Ускорить работу INSERT (faq читан)
|
|||
|---|---|---|---|
|
#18+
появились новые интересные данные Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. 32. 33. 34. 35. Как видно быстрее сделать 10 раз по 10000 записей чем один раз 100000. К чему бы это? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.05.2005, 20:41 |
|
||
|
Ускорить работу INSERT (faq читан)
|
|||
|---|---|---|---|
|
#18+
vfabr domanixТак вот - каждый update - рождает в таблице dev.current_data новую версию записи.. соответвенно при моллионе вставленных записей будет миллион версий записей в dev.current_data, ничего каждый UPDATE не рождает и ничего подобного вроде миллиона версий не будет. Те при простых UPDATE (как впрочем и INSERT зависимость будет линейная). Ага, не рождает :-) Попробуй следующее: Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. 32. 33. 34. 35. 36. 37. 38. При это логов накаталось на 8*16MB=128MB . Кто сказал, что логгирование не тормозит? :-) Настройки постгресса-по умолчанию. Кто добьется хорошего улучшения результата - сообщите. Как кто-то сказал (извини, что поленился найти), да и я сам пробовал, дешевле оказывается использовать plperl и его %_SHARED для накопления результата в FOR EACH ROW и потом сбрасывать результат в FOR EACH STATEMENT. Или еще где-нибудь. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.05.2005, 12:16 |
|
||
|
Ускорить работу INSERT (faq читан)
|
|||
|---|---|---|---|
|
#18+
Дополнение: Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. Затем: Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. Код: plaintext 1. 2. 3. 4. 5. 6. 7. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.05.2005, 13:00 |
|
||
|
Ускорить работу INSERT (faq читан)
|
|||
|---|---|---|---|
|
#18+
Алексей КлючниковКак видно быстрее сделать 10 раз по 10000 записей чем один раз 100000.Это можно было заметить и по моим результатам : 4m59.599s / 100 000 > 0m18.317s / 10 000. Но мы не заметили. :) Алексей КлючниковК чему бы это?К вопросу выбора оптимальной длины транзакции. Почему так происходит, не знаю. Funny_Falconupdate group_sum set amount=amount+NEW.ru where group_id=NEW.group_id -- Уже прошло 4970 секунд и не завершилось!попробуйте создать индекс на group_sum.group_id ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.05.2005, 13:15 |
|
||
|
Ускорить работу INSERT (faq читан)
|
|||
|---|---|---|---|
|
#18+
Второй день играю с параметрами в postgresql.conf пока не нашел что бы что то сильно влияло на скорость инсертов. тюнинг операционной системы совсем видимо не скоро удасться сделать ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.05.2005, 13:30 |
|
||
|
Ускорить работу INSERT (faq читан)
|
|||
|---|---|---|---|
|
#18+
Алексей Ключниковпока не нашел что бы что то сильно влияло на скорость инсертовfsync? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.05.2005, 13:34 |
|
||
|
Ускорить работу INSERT (faq читан)
|
|||
|---|---|---|---|
|
#18+
LeXa NalBat fsync Неа :) checkpoint_segments #checkpoint_timeout Вот этими параматрами можно сильно попортить скорость.. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.05.2005, 13:51 |
|
||
|
Ускорить работу INSERT (faq читан)
|
|||
|---|---|---|---|
|
#18+
LeXa NalBat Funny_Falcon update group_sum set amount=amount+NEW.ru where group_id=NEW.group_id -- Уже прошло 4970 секунд и не завершилось! попробуйте создать индекс на group_sum.group_id Извини, а group_id int PRIMARY KEY по твоему этого не делает ???????? Если нет, то я барсук. Но это еще надо доказать. Построй таблицу, залей в нее много данных (чтоб seqscan не выбирался) и сделай EXPLAIN запроса, содержащего условие по PRIMARY KEY. Там ты увидешь INDEX SCAN. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.05.2005, 17:36 |
|
||
|
Ускорить работу INSERT (faq читан)
|
|||
|---|---|---|---|
|
#18+
Funny_Falcon vfabr domanixТак вот - каждый update - рождает в таблице dev.current_data новую версию записи.. соответвенно при моллионе вставленных записей будет миллион версий записей в dev.current_data, ничего каждый UPDATE не рождает и ничего подобного вроде миллиона версий не будет. Те при простых UPDATE (как впрочем и INSERT зависимость будет линейная). Ага, не рождает :-) Попробуй следующее: первая причина почему не буду пробовать твой пример заключается хотя бы в том, что он не соответствует тому как действительно работает программа АК (смотри страницу 2). У тебя совершенно другая структура. Прежде чем ответить, возьми лист бумаги и нарисуй то что написал АК и то что придумал ты. А после этого посмотри еще раз мой пост [1488436]... И еще я придерживаюсь мнения что если запрос умещается в одну строку в экран то никакую ХП под него лепить не надо, а если не лепить ХП то в случае АК (основываясь на его примере см стр.2) ничего подобного ввиде миллиона записей не будет. далее почему процедура (тригерная) написана как plpgsql? почему не просто sql??? по моему есть разница ... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.05.2005, 12:43 |
|
||
|
Ускорить работу INSERT (faq читан)
|
|||
|---|---|---|---|
|
#18+
2 vfabr А ты пробовал триггерную функцию на SQL написать? Лично у меня (Postgres 8.0.2) выдаёт: ERROR: SQL functions cannot return type "trigger" на следующую конструкцию: Код: plaintext 1. 2. 3. 4. 5. А по поводу структуры: не один икс, вставлять в А, потом апдейтить в Б или апдейтить в Б, а потом вставлять в А? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.05.2005, 10:37 |
|
||
|
Ускорить работу INSERT (faq читан)
|
|||
|---|---|---|---|
|
#18+
про trigger на SQL меня бить надо потому что в доке написано что можно реализовать trigger на любом языке встроенном кроме как на чистом SQL :-/ спасибо FF я был не прав насчет А и Б я не скажу прям щас точно насчет логирования и пт но разница есть миллиона записей Update в случае АК не будет потому что происходит автокомит после вызова функции. Может и залогируется 1000000 Insertov, а может и нет. И вообще (ИМХО) структура не совсем верная у базы ... поэтому и тормоза ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.05.2005, 15:03 |
|
||
|
Ускорить работу INSERT (faq читан)
|
|||
|---|---|---|---|
|
#18+
vfabrмиллиона записей Update в случае АК не будет потому что происходит автокомит после вызова функции. Может и залогируется 1000000 Insertov, а может и нет. будут, но делаются по очереди а не пачкой, поэтому и автокоммит. vfabrИ вообще (ИМХО) структура не совсем верная у базы ... поэтому и тормоза Как же производить обработку информации? на current_data навешены набор правил и триггер который переклабывает в архив. ХП нужны в любом случае. Некоторые данные через правила проходят через 5-6 ХП до того как лягут в архив. Поэтому в любом случае нужна такая таблица как current_data, иначе все оберации придется делать в прямо в архиве.. на Данный момент обработке подвергаются 1-0.5% данных. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.05.2005, 14:40 |
|
||
|
Ускорить работу INSERT (faq читан)
|
|||
|---|---|---|---|
|
#18+
Funny_Falcon LeXa NalBat Funny_Falcon update group_sum set amount=amount+NEW.ru where group_id=NEW.group_id -- Уже прошло 4970 секунд и не завершилось! попробуйте создать индекс на group_sum.group_idИзвини, а group_id int PRIMARY KEY по твоему этого не делает ???????? Угу, слона то я и не заметил. Сорри, беру свой совет назад. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.05.2005, 12:01 |
|
||
|
Ускорить работу INSERT (faq читан)
|
|||
|---|---|---|---|
|
#18+
АКпоэтому и автокоммит автокоммит всегда происходит если не сказанно BEGIN [TRANSACTION] те явным образом не объявлена транзакция. Насчет структуры ... мне кажеться что нужна некоторая буферная таблица (без индексов и прочей мутотени) куда складываются данные (грязные) и потом их обрабатывать и раскидывать куда нужно. Вопрос в скорости отображения результатов полученных от датчиков. Может актуальность в 30 сек или 1 мин вполне приемлема тогда и тригеров и хранимок может меньше понадобится да и загрузка сервака меньше (ИМХО) должна быть ну и тд. (но поскольку я незнаю постановку задачи и темболее не знаю реализацию то все вышесказанное может быть совершенным бредом :-))) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.05.2005, 19:34 |
|
||
|
|

start [/forum/topic.php?all=1&fid=53&tid=2007264]: |
0ms |
get settings: |
8ms |
get forum list: |
16ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
55ms |
get topic data: |
12ms |
get forum data: |
3ms |
get page messages: |
123ms |
get tp. blocked users: |
2ms |
| others: | 261ms |
| total: | 486ms |

| 0 / 0 |
