Этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
Политика конфиденциальности
|
|
|
Производительность avg
|
|||
|---|---|---|---|
|
#18+
Тестовые таблицы Код: plaintext 1. 2. Тестовые запросы: Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. Размер каждой таблицы 3 млн. записей. Результаты Код: plaintext 1. 2. 3. 4. Почему происходит такое резкое падение производительности AVG на BIGINT? Пробовал AVG->SUM/COUNT запрос выполняется 7 секунд. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.06.2007, 14:28 |
|
||
|
Производительность avg
|
|||
|---|---|---|---|
|
#18+
ChameLe0nТестовые таблицы Почему происходит такое резкое падение производительности AVG на BIGINT? Potomu chto avg(bigint) aggregat vozvrashaet tip numeric, i ispolzuet numeric v processe nakoplenia. Tak kak operatsii s tipom numeric dostatochno trudoemki, to poetomu avg(bigint) takoi medlennyi. A avg(int) ispolzuet v processe rascheta int64. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.06.2007, 15:24 |
|
||
|
Производительность avg
|
|||
|---|---|---|---|
|
#18+
Не забывайте еще про ширину таблицы. Т.е. запись в таблице 5 - физически в два раза шире записи в таблице 1. И при агрегации таблицы 5 гораздо больше требуется операций с диском. Т.к. в кеш помещаться будет меньше страниц. Что влечет за собой дополнительные операции по чтению.. Попробуйте просто задать Count(*) для обеих таблиц- увидете разницу... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.06.2007, 16:53 |
|
||
|
Производительность avg
|
|||
|---|---|---|---|
|
#18+
СергейК ChameLe0nТестовые таблицы Почему происходит такое резкое падение производительности AVG на BIGINT? Potomu chto avg(bigint) aggregat vozvrashaet tip numeric, i ispolzuet numeric v processe nakoplenia. Tak kak operatsii s tipom numeric dostatochno trudoemki, to poetomu avg(bigint) takoi medlennyi. A avg(int) ispolzuet v processe rascheta int64.а зачем avg-у пользовать тип, больший чем тип поля? Или трудно вычислить avg от N+1 записи, зная avg предыдущих N (размерность - та же, что и у поля), значение поля в N+1 записи (размерност ь - та же, что и поле) и само это N? не корысти ради, а просто расскажите, в чем же проблема? Или складывать цифирьки с весами, отличными от 1-ы - столь трудное занятие? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.06.2007, 16:54 |
|
||
|
Производительность avg
|
|||
|---|---|---|---|
|
#18+
assa СергейК ChameLe0nТестовые таблицы Почему происходит такое резкое падение производительности AVG на BIGINT? Potomu chto avg(bigint) aggregat vozvrashaet tip numeric, i ispolzuet numeric v processe nakoplenia. Tak kak operatsii s tipom numeric dostatochno trudoemki, to poetomu avg(bigint) takoi medlennyi. A avg(int) ispolzuet v processe rascheta int64.а зачем avg-у пользовать тип, больший чем тип поля? Или трудно вычислить avg от N+1 записи, зная avg предыдущих N (размерность - та же, что и у поля), значение поля в N+1 записи (размерност ь - та же, что и поле) и само это N? не корысти ради, а просто расскажите, в чем же проблема? Или складывать цифирьки с весами, отличными от 1-ы - столь трудное занятие? Potomu chto vse aggregaty snachala nakaplivaut, a potom v samom kontse vychisliaut rezultat. Aggregatnye functsii nikogda ne znaut, skolko zapisei proidet cherez nih. Poetomu avg ustroen tak: Pri kajdoi novoi postupaushei zapisi on dobavliaet novoe chislo k summe vseh predydushih chisel i uvelichivaet na 1chku schetchik kol-va chisel proshedshih cherez nego. A v samom kontse on delit odno na drugoe.. A ispolzuetsia tip bolshii razmera polia chtoby ne bylo perepolnenia pri summirovanii ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.06.2007, 17:44 |
|
||
|
Производительность avg
|
|||
|---|---|---|---|
|
#18+
domanixНе забывайте еще про ширину таблицы. Т.е. запись в таблице 5 - физически в два раза шире записи в таблице 1. И при агрегации таблицы 5 гораздо больше требуется операций с диском. Т.к. в кеш помещаться будет меньше страниц. Что влечет за собой дополнительные операции по чтению.. Попробуйте просто задать Count(*) для обеих таблиц- увидете разницу... Ne, tut eto deistvitelno ne osobo vajno. Esli proverit' na prostenkih tablichkah : create table xx as select generate_series::bigint from generate_series(1,100000); create table xx1 as select generate_series from generate_series(1,100000); vidno chto bigint avg() v cachirovannom rejime v 10 raz medlennee ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.06.2007, 18:10 |
|
||
|
Производительность avg
|
|||
|---|---|---|---|
|
#18+
СергейК assaа зачем avg-у пользовать тип, больший чем тип поля? Или трудно вычислить avg от N+1 записи, зная avg предыдущих N (размерность - та же, что и у поля), значение поля в N+1 записи (размерност ь - та же, что и поле) и само это N? не корысти ради, а просто расскажите, в чем же проблема? Или складывать цифирьки с весами, отличными от 1-ы - столь трудное занятие? Potomu chto vse aggregaty snachala nakaplivaut, a potom v samom kontse vychisliaut rezultat. Aggregatnye functsii nikogda ne znaut, skolko zapisei proidet cherez nih. Poetomu avg ustroen tak: Pri kajdoi novoi postupaushei zapisi on dobavliaet novoe chislo k summe vseh predydushih chisel i uvelichivaet na 1chku schetchik kol-va chisel proshedshih cherez nego. A v samom kontse on delit odno na drugoe.. A ispolzuetsia tip bolshii razmera polia chtoby ne bylo perepolnenia pri summirovanii вы читать не умеете, или ,кхм, придуриваетесь? проводя на каждом шаге нормировку мы избавляемся от необходимости увеличивать разрядность накопителя. действительно ли это (нормирование на шаге) дороже, чем пользовать неприятный вам тип "ньюмерик"? Или речь идет о (возможном) накоплении ошибки (при нормировке)? (кстати, а это самое "накопление" там будет?) Просветите, но все же в чем реальные причины выбора в пользу "расширенного типа". (ну не в алгоритмической импотенции, вжеж). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.06.2007, 18:16 |
|
||
|
Производительность avg
|
|||
|---|---|---|---|
|
#18+
assaа зачем avg-у пользовать тип, больший чем тип поля? Или трудно вычислить avg от N+1 записи, зная avg предыдущих N (размерность - та же, что и у поля), значение поля в N+1 записи (размерност ь - та же, что и поле) и само это N? не корысти ради, а просто расскажите, в чем же проблема? Или складывать цифирьки с весами, отличными от 1-ы - столь трудное занятие? А как вы будете вычислять avg N+1 записи, зная avg предыущих? Например, как вы будете вычислять средние значения на каждом шаге у следующей последовательности? 1 2 1 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.06.2007, 18:41 |
|
||
|
Производительность avg
|
|||
|---|---|---|---|
|
#18+
assa проводя на каждом шаге нормировку мы избавляемся от необходимости увеличивать разрядность накопителя. действительно ли это (нормирование на шаге) дороже, чем пользовать неприятный вам тип "ньюмерик"? Или речь идет о (возможном) накоплении ошибки (при нормировке)? (кстати, а это самое "накопление" там будет?) Просветите, но все же в чем реальные причины выбора в пользу "расширенного типа". (ну не в алгоритмической импотенции, вжеж). Накопление ошибки ИМХО действительно будет иметь место. на каждом шагу умножение и два деления + округление. Ваш алгоритм (число накопления A64, NUM - приемник, N - шаг): A64=trunc(A64*((N-1)/N)+B64/N) в то время как PGшный не накаплтивает ошибки вообще. Кста, а что мешает написать самому агрегат который будет реализовывать именно Ваше видение среднего? Заодно и точность сравнить. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.06.2007, 19:04 |
|
||
|
Производительность avg
|
|||
|---|---|---|---|
|
#18+
msa@n-e.ru assaа зачем avg-у пользовать тип, больший чем тип поля? Или трудно вычислить avg от N+1 записи, зная avg предыдущих N (размерность - та же, что и у поля), значение поля в N+1 записи (размерност ь - та же, что и поле) и само это N? А как вы будете вычислять avg N+1 записи, зная avg предыущих? Например, как вы будете вычислять средние значения на каждом шаге у следующей последовательности? 1 2 1 вы издеваетесь, или читать не умеете? если умеете, и при этом не думали издеваться.. - я даже затрудняюсь... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.06.2007, 19:16 |
|
||
|
Производительность avg
|
|||
|---|---|---|---|
|
#18+
msa@n-e.ru А как вы будете вычислять avg N+1 записи, зная avg предыущих? Например, как вы будете вычислять средние значения на каждом шаге у следующей последовательности? 1 2 1 Достаточно знать еще и номер шага. А это легко реализуется композитным внутренним типом аггрегата в постгресе. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.06.2007, 19:20 |
|
||
|
Производительность avg
|
|||
|---|---|---|---|
|
#18+
assa вы читать не умеете, или ,кхм, придуриваетесь? Просветите, но все же в чем реальные причины выбора в пользу "расширенного типа". (ну не в алгоритмической импотенции, вжеж). Esli u vas takaia horoshaia algoritmicheskaia potentsia, to napishite sami takoi aggregat, otprav'te v pg-patches i uvidite chto vash patch ne primut (po prichinam izlozhennym Andrey Daeron ) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.06.2007, 19:45 |
|
||
|
Производительность avg
|
|||
|---|---|---|---|
|
#18+
Код: plaintext Код: plaintext 1. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.06.2007, 05:29 |
|
||
|
Производительность avg
|
|||
|---|---|---|---|
|
#18+
domanixНе забывайте еще про ширину таблицы. Т.е. запись в таблице 5 - физически в два раза шире записи в таблице 1. И при агрегации таблицы 5 гораздо больше требуется операций с диском. Т.к. в кеш помещаться будет меньше страниц. Что влечет за собой дополнительные операции по чтению.. Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. Учитывая что на тестовой машинке стоят SATA винты и скорость чтения ~50Мб/сек, таблицы читаются с диска ~: 1 - 5 сек 2 - 7 сек 3 - 6 сек Однако все результаты, которые я предоставлял являются повторным выполнением запроса, те таблицы читаются уже из памяти. авторПопробуйте просто задать Count(*) для обеих таблиц- увидете разницу... ок - назовем условно его запрос 3 Код: plaintext 1. 2. 3. 4. 5. 6. 7. Код: plaintext 1. На всякий случай: Intel Core Duo 4300, 4 Gb памяти, PG 8.2.4, 2.6.18-8.el5 #1 SMP Thu Mar 15 19:46:53 EDT 2007 x86_64 x86_64 x86_64 GNU/Linux ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.06.2007, 05:41 |
|
||
|
Производительность avg
|
|||
|---|---|---|---|
|
#18+
СергейК Potomu chto avg(bigint) aggregat vozvrashaet tip numeric, i ispolzuet numeric v processe nakoplenia. Tak kak operatsii s tipom numeric dostatochno trudoemki, to poetomu avg(bigint) takoi medlennyi. A avg(int) ispolzuet v processe rascheta int64. Напишем новый запрос: Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. Код: plaintext ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.06.2007, 05:51 |
|
||
|
Производительность avg
|
|||
|---|---|---|---|
|
#18+
СергейК assa вы читать не умеете, или ,кхм, придуриваетесь? Просветите, но все же в чем реальные причины выбора в пользу "расширенного типа". (ну не в алгоритмической импотенции, вжеж). Esli u vas takaia horoshaia algoritmicheskaia potentsia, to napishite sami takoi aggregat, otprav'te v pg-patches i uvidite chto vash patch ne primut (po prichinam izlozhennym Andrey Daeron ) По-моему АССа умеет только ухмылятся и хамить, врядли от него можно дождаться каких-то умных мыслей ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.06.2007, 10:07 |
|
||
|
Производительность avg
|
|||
|---|---|---|---|
|
#18+
70% постов в ветке ms access обязывает :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.06.2007, 10:18 |
|
||
|
Производительность avg
|
|||
|---|---|---|---|
|
#18+
Andrey DaeronНакопление ошибки ИМХО действительно будет иметь место. на каждом шагу умножение и два деления + округление. Ваш алгоритм (число накопления A64, NUM - приемник, N - шаг): A64=trunc(A64*((N-1)/N)+B64/N) в то время как PGшный не накаплтивает ошибки вообще. Кста, а что мешает написать самому агрегат который будет реализовывать именно Ваше видение среднего? Заодно и точность сравнить.округление тут лишнее. в качестве накопителя среднего нужно пользовать float8, т.к среднее - как правило не целое. относительная ошибка на шаге - погрешность флоата. Относительная ошибка суммирования для чисел одного знако не превысит наибольшей относительной ошибки слагаемого. А вот при слагаемых разных знаков можно действительно получить неприятный результат. ЗЫ Алгоритм же от PG таки имеет ошибку. А именно - ошибку представления результата деления в число с ограниченной разрядностью. В случае знакопеременного ряда она, видимо, может оказаться много меньше ошибки алгоритма с норимрованием на шаге (при среднем от модуля много большем среднего) . А вот в случае знакопостоянного - того же порядка. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.06.2007, 10:32 |
|
||
|
Производительность avg
|
|||
|---|---|---|---|
|
#18+
st_serg70% постов в ветке ms access обязывает :)смайлеги, смайлеги. многа смайлегов. зы. что-то имеем сказать по делу? или так - пофлудеть вышли? :0) зы2. г-н msa (видимо с M$SQL) попросту имел неосторожность нести чушь в одном из топегов (о связи табличек без джойна) на прошлой неделе. На чем его немного пощучили. Т.ч. он "имеет право" подуцца. Т.с. - "не мешки ворочать". ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.06.2007, 10:39 |
|
||
|
Производительность avg
|
|||
|---|---|---|---|
|
#18+
assa st_serg70% постов в ветке ms access обязывает :)смайлеги, смайлеги. многа смайлегов. зы. что-то имеем сказать по делу? или так - пофлудеть вышли? :0) зы2. г-н msa (видимо с M$SQL) попросту имел неосторожность нести чушь в одном из топегов (о связи табличек без джойна) на прошлой неделе. На чем его немного пощучили. Т.ч. он "имеет право" подуцца. Т.с. - "не мешки ворочать". Чушь несли вы ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.06.2007, 11:13 |
|
||
|
Производительность avg
|
|||
|---|---|---|---|
|
#18+
ChameLe0n СергейКavg(bigint) aggregat ... ispolzuet numeric Код: plaintext Код: plaintext assaа зачем avg-у пользовать тип, больший чем тип поля?Этот вопрос наверное лучше задать разаработчикам постгреса... assaпроводя на каждом шаге нормировку мы избавляемся от необходимости увеличивать разрядность накопителя. действительно ли это (нормирование на шаге) дороже, чем пользовать неприятный вам тип "ньюмерик"?Вроде бы нормирование bigint на каждом шаге дешевле, чем суммирование numeric. Код: plaintext 1. 2. 3. 4. 5. 6. Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.06.2007, 12:29 |
|
||
|
|

start [/forum/topic.php?fid=53&msg=34593002&tid=2005362]: |
0ms |
get settings: |
7ms |
get forum list: |
16ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
68ms |
get topic data: |
12ms |
get forum data: |
2ms |
get page messages: |
61ms |
get tp. blocked users: |
1ms |
| others: | 221ms |
| total: | 394ms |

| 0 / 0 |
