powered by simpleCommunicator - 2.0.60     © 2026 Programmizd 02
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Форумы / PostgreSQL [игнор отключен] [закрыт для гостей] / Производительность avg
21 сообщений из 21, страница 1 из 1
Производительность avg
    #34591837
ChameLe0n
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Тестовые таблицы
Код: plaintext
1.
2.
CREATE TABLE public.table1 (id SERIAL,gr1 int REFERENCES group1(id),f1 INTEGER,f2 INTEGER,f3 INTEGER,f4 INTEGER,f5 INTEGER,txt CHAR( 10 ),PRIMARY KEY(id)) WITH OIDS

CREATE TABLE public.table5 (id SERIAL,gr1 int REFERENCES group1(id),f1 BIGINT,f2 BIGINT,f3 BIGINT,f4 BIGINT,f5 BIGINT,txt CHAR( 10 ),PRIMARY KEY(id)) WITH OIDS
Как видно отличаются только типы 5 полей INT->BIGINT

Тестовые запросы:
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
select 
    gr1, sum(f1), min(f2), max(f3)
from
    tableX, где X =  1 , 5 
group by 
     1 
order by
     1 

select 
    gr1, sum(f1), min(f2), max(f3), avg(f4)
from
    tableX
group by 
     1 
order by
     1 

Размер каждой таблицы 3 млн. записей.
Результаты
Код: plaintext
1.
2.
3.
4.
 1 -й запрос 
Таблица  1 :  1 , 4  секунды          Таблица  5 :  5 , 3  секунды
 2 -й запрос 
Таблица  1 :  1 , 7  секунды          Таблица  5 :  14 , 0  секунды

Почему происходит такое резкое падение производительности AVG на BIGINT? Пробовал AVG->SUM/COUNT запрос выполняется 7 секунд.
...
Рейтинг: 0 / 0
Производительность avg
    #34592091
СергейК
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
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.
...
Рейтинг: 0 / 0
Производительность avg
    #34592510
domanix
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Не забывайте еще про ширину таблицы.
Т.е. запись в таблице 5 - физически в два раза шире записи в таблице 1.
И при агрегации таблицы 5 гораздо больше требуется операций с диском. Т.к. в кеш помещаться будет меньше страниц. Что влечет за собой дополнительные операции по чтению..
Попробуйте просто задать Count(*) для обеих таблиц- увидете разницу...
...
Рейтинг: 0 / 0
Производительность avg
    #34592516
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-ы - столь трудное занятие?
...
Рейтинг: 0 / 0
Производительность avg
    #34592751
СергейК
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
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
...
Рейтинг: 0 / 0
Производительность avg
    #34592831
СергейК
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
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
...
Рейтинг: 0 / 0
Производительность avg
    #34592849
assa
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
СергейК 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
вы читать не умеете, или ,кхм, придуриваетесь?


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

Просветите, но все же в чем реальные причины выбора в пользу "расширенного типа". (ну не в алгоритмической импотенции, вжеж).
...
Рейтинг: 0 / 0
Производительность avg
    #34592922
msa@n-e.ru
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
assaа зачем avg-у пользовать тип, больший чем тип поля? Или трудно вычислить avg от N+1 записи, зная avg предыдущих N (размерность - та же, что и у поля), значение поля в N+1 записи (размерност ь - та же, что и поле) и само это N?

не корысти ради, а просто расскажите, в чем же проблема? Или складывать цифирьки с весами, отличными от 1-ы - столь трудное занятие?

А как вы будете вычислять avg N+1 записи, зная avg предыущих?

Например, как вы будете вычислять средние значения на каждом шаге у следующей последовательности?

1
2
1
...
Рейтинг: 0 / 0
Производительность avg
    #34592978
Andrey Daeron
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
assa
проводя на каждом шаге нормировку мы избавляемся от необходимости увеличивать разрядность накопителя. действительно ли это (нормирование на шаге) дороже, чем пользовать неприятный вам тип "ньюмерик"? Или речь идет о (возможном) накоплении ошибки (при нормировке)? (кстати, а это самое "накопление" там будет?)

Просветите, но все же в чем реальные причины выбора в пользу "расширенного типа". (ну не в алгоритмической импотенции, вжеж).
Накопление ошибки ИМХО действительно будет иметь место. на каждом шагу умножение и два деления + округление.

Ваш алгоритм (число накопления A64, NUM - приемник, N - шаг):
A64=trunc(A64*((N-1)/N)+B64/N)
в то время как PGшный не накаплтивает ошибки вообще.

Кста, а что мешает написать самому агрегат который будет реализовывать именно Ваше видение среднего? Заодно и точность сравнить.
...
Рейтинг: 0 / 0
Производительность avg
    #34593002
assa
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
msa@n-e.ru assaа зачем avg-у пользовать тип, больший чем тип поля? Или трудно вычислить avg от N+1 записи, зная avg предыдущих N (размерность - та же, что и у поля), значение поля в N+1 записи (размерност ь - та же, что и поле) и само это N?


А как вы будете вычислять avg N+1 записи, зная avg предыущих?

Например, как вы будете вычислять средние значения на каждом шаге у следующей последовательности?

1
2
1
вы издеваетесь, или читать не умеете?
если умеете, и при этом не думали издеваться.. - я даже затрудняюсь...
...
Рейтинг: 0 / 0
Производительность avg
    #34593013
Andrey Daeron
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
msa@n-e.ru
А как вы будете вычислять avg N+1 записи, зная avg предыущих?

Например, как вы будете вычислять средние значения на каждом шаге у следующей последовательности?

1
2
1
Достаточно знать еще и номер шага. А это легко реализуется композитным внутренним типом аггрегата в постгресе.
...
Рейтинг: 0 / 0
Производительность avg
    #34593067
СергейК
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
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 )
...
Рейтинг: 0 / 0
Производительность avg
    #34593423
ChameLe0n
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Код: plaintext
CREATE TABLE public.table3 (id SERIAL,gr1 int REFERENCES group1(id),f1 numeric( 20 , 2 ),f2 numeric( 20 , 2 ),f3 numeric( 20 , 2 ),f4 numeric( 20 , 2 ),f5 numeric( 20 , 2 ),txt CHAR( 10 ),PRIMARY KEY(id)) WITH OIDS 

Код: plaintext
1.
Запрос  1 :  3 , 5   секунды                 Запрос  2 :  9 , 4  секунды
...
Рейтинг: 0 / 0
Производительность avg
    #34593426
ChameLe0n
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
domanixНе забывайте еще про ширину таблицы.
Т.е. запись в таблице 5 - физически в два раза шире записи в таблице 1.
И при агрегации таблицы 5 гораздо больше требуется операций с диском. Т.к. в кеш помещаться будет меньше страниц. Что влечет за собой дополнительные операции по чтению..

Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
select relname,relpages* 8 / 1024 ||' Мб', (reltuples/ 1000000 )::numeric( 5 , 1 )||' млн' from pg_class where relname ~ 'table[1,3,5]$' order by relname

 relname     ?column?     ?column?    
 ----------  -----------  ----------- 
 table1       244  Мб        3 . 0  млн     
 table3       360  Мб        3 . 0  млн     
 table5       312  Мб        3 . 0  млн     

  3  record(s) selected [Fetch MetaData:  1 /ms] [Fetch Data:  0 /ms] 


Учитывая что на тестовой машинке стоят SATA винты и скорость чтения ~50Мб/сек, таблицы читаются с диска ~:
1 - 5 сек
2 - 7 сек
3 - 6 сек

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


авторПопробуйте просто задать Count(*) для обеих таблиц- увидете разницу...
ок - назовем условно его запрос 3
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
select 
    gr1, sum(f1), min(f2), max(f3), count(*)
from
    tableX, где X =  1 , 3 , 5 
group by 
     1 
order by
     1 

Код: plaintext
1.
Таблица  1 :   1 , 6   сек           Таблица  3 :  3 , 2  сек            Таблица  5 :  4 , 8  сек

На всякий случай:
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
...
Рейтинг: 0 / 0
Производительность avg
    #34593431
ChameLe0n
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
СергейК
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.
select 
    t.gr1,
    sum(f1),
     min(f2),
    max(f3),
    sum(f4)/count(*)
from
    table1 t

group by 
     1 
order by
     1 

Код: plaintext
Таблица  1 :  1 , 7  сек            Таблица  3 :  4 , 7  сек       Таблица  5 :  8 , 0  сек
Что является практически вдвое лучшим результатом по сравнению с avg (для таблицы 5). Кстати об этом я писал в своем первом посте, однако на это никто не обратил внимание.
...
Рейтинг: 0 / 0
Производительность avg
    #34593729
msa@n-e.ru
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
СергейК 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 )

По-моему АССа умеет только ухмылятся и хамить, врядли от него можно дождаться каких-то умных мыслей
...
Рейтинг: 0 / 0
Производительность avg
    #34593768
st_serg
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
70% постов в ветке ms access обязывает :)
...
Рейтинг: 0 / 0
Производительность avg
    #34593809
assa
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Andrey DaeronНакопление ошибки ИМХО действительно будет иметь место. на каждом шагу умножение и два деления + округление.

Ваш алгоритм (число накопления A64, NUM - приемник, N - шаг):
A64=trunc(A64*((N-1)/N)+B64/N)
в то время как PGшный не накаплтивает ошибки вообще.

Кста, а что мешает написать самому агрегат который будет реализовывать именно Ваше видение среднего? Заодно и точность сравнить.округление тут лишнее. в качестве накопителя среднего нужно пользовать float8, т.к среднее - как правило не целое. относительная ошибка на шаге - погрешность флоата. Относительная ошибка суммирования для чисел одного знако не превысит наибольшей относительной ошибки слагаемого. А вот при слагаемых разных знаков можно действительно получить неприятный результат.

ЗЫ Алгоритм же от PG таки имеет ошибку. А именно - ошибку представления результата деления в число с ограниченной разрядностью. В случае знакопеременного ряда она, видимо, может оказаться много меньше ошибки алгоритма с норимрованием на шаге (при среднем от модуля много большем среднего) . А вот в случае знакопостоянного - того же порядка.
...
Рейтинг: 0 / 0
Производительность avg
    #34593842
assa
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
st_serg70% постов в ветке ms access обязывает :)смайлеги, смайлеги. многа смайлегов.


зы. что-то имеем сказать по делу? или так - пофлудеть вышли? :0)

зы2. г-н msa (видимо с M$SQL) попросту имел неосторожность нести чушь в одном из топегов (о связи табличек без джойна) на прошлой неделе. На чем его немного пощучили. Т.ч. он "имеет право" подуцца. Т.с. - "не мешки ворочать".
...
Рейтинг: 0 / 0
Производительность avg
    #34593946
msa@n-e.ru
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
assa st_serg70% постов в ветке ms access обязывает :)смайлеги, смайлеги. многа смайлегов.


зы. что-то имеем сказать по делу? или так - пофлудеть вышли? :0)

зы2. г-н msa (видимо с M$SQL) попросту имел неосторожность нести чушь в одном из топегов (о связи табличек без джойна) на прошлой неделе. На чем его немного пощучили. Т.ч. он "имеет право" подуцца. Т.с. - "не мешки ворочать".

Чушь несли вы
...
Рейтинг: 0 / 0
Производительность avg
    #34594241
LeXa NalBat
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ChameLe0n СергейКavg(bigint) aggregat ... ispolzuet numeric
Код: plaintext
sum(f4)/count(*)
Код: plaintext
Таблица  1 :  1 , 7  сек            Таблица  3 :  4 , 7  сек       Таблица  5 :  8 , 0  сек
Что является практически вдвое лучшим результатом по сравнению с avg (для таблицы 5). Кстати об этом я писал в своем первом посте, однако на это никто не обратил внимание.Внимание сразу обратил, и сразу провел эскперимент. Ничего не написал потому что получил скорости выполнения аналогичные вашим - avg(bigint) в 1.5-2 раза медленнее sum/count. При этом результаты вычислений avg и sum/count получились абсолютно одинаковые.

assaа зачем avg-у пользовать тип, больший чем тип поля?Этот вопрос наверное лучше задать разаработчикам постгреса...

assaпроводя на каждом шаге нормировку мы избавляемся от необходимости увеличивать разрядность накопителя. действительно ли это (нормирование на шаге) дороже, чем пользовать неприятный вам тип "ньюмерик"?Вроде бы нормирование bigint на каждом шаге дешевле, чем суммирование numeric.
Код: plaintext
1.
2.
3.
4.
5.
6.
create table test ( f1 bigint, f2 bigint, f3 bigint );
insert into test select  1 + 1000000 *random(),  1 + 1000000 *random(),  1 + 1000000 *random() from generate_series( 1 , 1000000 );
VACUUM ANALYZE test;
explain analyze select avg(f1) from test;
explain analyze select avg(f1) from test;
explain analyze select sum(f1*f2/f3) from test;
explain analyze select sum(f1*f2/f3) from test;
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
nalbat=> explain analyze select avg(f1) from test;
                                                      QUERY PLAN
-----------------------------------------------------------------------------------------------------------------------
 Aggregate  (cost= 19853 . 00 .. 19853 . 01  rows= 1  width= 8 ) (actual time= 6599 . 840 .. 6599 . 843  rows= 1  loops= 1 )
   ->  Seq Scan on test  (cost= 0 . 00 .. 17353 . 00  rows= 1000000  width= 8 ) (actual time= 0 . 046 .. 2355 . 822  rows= 1000000  loops= 1 )
 Total runtime:  6599 . 902  ms
( 3  rows)

nalbat=> explain analyze select sum(f1*f2/f3) from test;
                                                       QUERY PLAN
------------------------------------------------------------------------------------------------------------------------
 Aggregate  (cost= 19853 . 00 .. 19853 . 02  rows= 1  width= 24 ) (actual time= 5383 . 438 .. 5383 . 441  rows= 1  loops= 1 )
   ->  Seq Scan on test  (cost= 0 . 00 .. 17353 . 00  rows= 1000000  width= 24 ) (actual time= 0 . 042 .. 2332 . 209  rows= 1000000  loops= 1 )
 Total runtime:  5383 . 490  ms
( 3  rows)
...
Рейтинг: 0 / 0
21 сообщений из 21, страница 1 из 1
Форумы / PostgreSQL [игнор отключен] [закрыт для гостей] / Производительность avg
Найденые пользователи ...
Разблокировать пользователей ...
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]