|
|
|
аналог on duplicate key update оптимизация и костыли...
|
|||
|---|---|---|---|
|
#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. и собственно нужно что бы при insert'е, если нету позиции с уникальной парой склад-товар вставить, иначе сделать update с установкой "count"="count"+new."count" Пытался сделать как писали в гугле. Получалось например при добавлении с "count" 1 10 100 в результате не 111 а 112... (Собственно про это предупреждали) Вариант с процедурой отверг т.к. мне нужно будет вставлять из таблицы в таблицу. сделал вот так: Код: plaintext 1. 2. 3. 4. 5. ------- Собственно вопрос: Это я такой идиот или всё действительно так плохо? + Что посоветуете для оптимизации? ------- P.S.: На pg_sql 2й день, но всё же прежде чем давать советы, и указывать на мою глупость, прочитайте внимательно вопрос. Заранее спасибо! ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.10.2010, 03:19:17 |
|
||
|
аналог on duplicate key update оптимизация и костыли...
|
|||
|---|---|---|---|
|
#18+
Aicg, так как Вы не хотите блокировать таблицу, Вам нужно делать цикл, в котором Вы будете пытаться обновить или вставить, до тех пор пока обновление или вставка не выполнятся успешно. Например как в документации: http://www.postgresql.org/docs/current/static/plpgsql-control-structures.html#PLPGSQL-UPSERT-EXAMPLE Так как Вы не хотите использовать функцию, Вам нужно это делать в триггере. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.10.2010, 03:45:24 |
|
||
|
аналог on duplicate key update оптимизация и костыли...
|
|||
|---|---|---|---|
|
#18+
Aicg, а в чем собственно сложность сделать before insert pl/pgsql триггер который бы делал то что вам надо. Это же стандартное решение. PS: забудьте про rules (50% наиболее странных и нерешаемых вопросов в этом форуме как раз посвящены рулам). Есть мнение что в 9.2 rules спилят наконец совсем с базы как неработоспособный ужас. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.10.2010, 03:50:31 |
|
||
|
аналог on duplicate key update оптимизация и костыли...
|
|||
|---|---|---|---|
|
#18+
Так если я выполню http://www.postgresql.org/docs/current/static/plpgsql-control-structures.html#PLPGSQL-UPSERT-EXAMPLE в before insert триггере, то не получится ли бесконечного цикла при записи внутри самого триггера(before insert trigger + insert в нем), как получилось при моей попытки организовать такое с правилами? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.10.2010, 03:55:02 |
|
||
|
аналог on duplicate key update оптимизация и костыли...
|
|||
|---|---|---|---|
|
#18+
В общем я вроде разобрался. Код: plaintext 1. 2. 3. 4. 5. 6. Всем спасибо, надо было мне внимательнее читать... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.10.2010, 04:25:55 |
|
||
|
аналог on duplicate key update оптимизация и костыли...
|
|||
|---|---|---|---|
|
#18+
Подскажите, пожалуйста, в 9.2 есть аналог myslq-евской «ON DUPLICATE KEY UPDATE»? Есть две выборки с данными(p_key, data_field), который пересекаются по ключу только частично. Нужно скомпоновать таблицу с обоими выборками, при совпадении ключей, data_field просуммировать. Какой способ реализации в функции будет быстрее: 1. через временную таблицу (p_key, data_field, table_key), делаем два селекта с разными table_key, а потом результирующий insert c group by. 2. Первую выборку пихаем в таблицу, потом через update при совпадении + insert при отсутствии p_key. 3. Какой-то другой способ. Поскольку выборки тяжеловесные, то, мне кажется, первый способ будет менее накладным, т.к. в нем всего один тяжеловесный запрос. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.05.2014, 08:25:27 |
|
||
|
аналог on duplicate key update оптимизация и костыли...
|
|||
|---|---|---|---|
|
#18+
PavelVXПодскажите, пожалуйста, в 9.2 есть аналог myslq-евской «ON DUPLICATE KEY UPDATE»? Есть две выборки с данными(p_key, data_field), который пересекаются по ключу только частично. Нужно скомпоновать таблицу с обоими выборками, при совпадении ключей, data_field просуммировать. Какой способ реализации в функции будет быстрее: 1. через временную таблицу (p_key, data_field, table_key), делаем два селекта с разными table_key, а потом результирующий insert c group by. 2. Первую выборку пихаем в таблицу, потом через update при совпадении + insert при отсутствии p_key. 3. Какой-то другой способ. Поскольку выборки тяжеловесные, то, мне кажется, первый способ будет менее накладным, т.к. в нем всего один тяжеловесный запрос. insert into .... (p_key, data_field) select coalesce(t1.p_key, t2.p_key) as p_key, coalesce(t1.data_field, 0) + coalesce(t2.data_field, 0) from table1 t1 full join table2 t2 on t1.p_key = t2.p_key; ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.05.2014, 13:50:22 |
|
||
|
аналог on duplicate key update оптимизация и костыли...
|
|||
|---|---|---|---|
|
#18+
Ivan Durakinsert into .... (p_key, data_field) select coalesce(t1.p_key, t2.p_key) as p_key, coalesce(t1.data_field, 0) + coalesce(t2.data_field, 0) from table1 t1 full join table2 t2 on t1.p_key = t2.p_key; Спасибо!!! Моя нелюбовь к full join меня подвела :( ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.05.2014, 11:03:22 |
|
||
|
аналог on duplicate key update оптимизация и костыли...
|
|||
|---|---|---|---|
|
#18+
PavelVXIvan Durakinsert into .... (p_key, data_field) select coalesce(t1.p_key, t2.p_key) as p_key, coalesce(t1.data_field, 0) + coalesce(t2.data_field, 0) from table1 t1 full join table2 t2 on t1.p_key = t2.p_key; Спасибо!!! Моя нелюбовь к full join меня подвела :( я бы скорее через union all + group by бы делал... оно возможно быстрее будет на больших таблицах Код: plsql 1. 2. 3. 4. 5. 6. 7. 8. 9. --Maxim Boguk www.postgresql-consulting.ru ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.05.2014, 11:23:50 |
|
||
|
аналог on duplicate key update оптимизация и костыли...
|
|||
|---|---|---|---|
|
#18+
Хмм, через юнион тоже можно. Идеологически это напоминает вариант как со временной таблицей. Только без таблицы :) Но сдается мне, это будет дольше, чем через времянку, поскольку у меня t1/t2 это как пример, на самом деле там выборки с кучей join, в которых участвуют общие для выборок таблицы. Вариант через времянку, на 1.5 млн. строк сырых данных/150тыс итоговых, выполняется на 2 секунды быстрее(в среднем 50 сек) чем через full join(52 сек в среднем). В общем, поскольку это стат данные, и вычисляются по расписанию, забил на +/- пару секунд. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.05.2014, 11:53:13 |
|
||
|
|

start [/forum/topic.php?fid=53&fpage=128&tid=1998684]: |
0ms |
get settings: |
6ms |
get forum list: |
12ms |
check forum access: |
2ms |
check topic access: |
2ms |
track hit: |
380ms |
get topic data: |
7ms |
get forum data: |
2ms |
get page messages: |
27ms |
get tp. blocked users: |
1ms |
| others: | 195ms |
| total: | 634ms |

| 0 / 0 |
