Гость
Целевая тема:
Создать новую тему:
Автор:
Форумы / PostgreSQL [игнор отключен] [закрыт для гостей] / Производительность avg / 21 сообщений из 21, страница 1 из 1
13.06.2007, 14:28
    #34591837
ChameLe0n
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Производительность avg
Тестовые таблицы
Код: 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
13.06.2007, 15:24
    #34592091
СергейК
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Производительность avg
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
13.06.2007, 16:53
    #34592510
domanix
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Производительность avg
Не забывайте еще про ширину таблицы.
Т.е. запись в таблице 5 - физически в два раза шире записи в таблице 1.
И при агрегации таблицы 5 гораздо больше требуется операций с диском. Т.к. в кеш помещаться будет меньше страниц. Что влечет за собой дополнительные операции по чтению..
Попробуйте просто задать Count(*) для обеих таблиц- увидете разницу...
...
Рейтинг: 0 / 0
13.06.2007, 16:54
    #34592516
assa
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Производительность avg
СергейК 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
13.06.2007, 17:44
    #34592751
СергейК
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Производительность avg
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
13.06.2007, 18:10
    #34592831
СергейК
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Производительность avg
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
13.06.2007, 18:16
    #34592849
assa
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Производительность avg
СергейК 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
13.06.2007, 18:41
    #34592922
msa@n-e.ru
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Производительность avg
assaа зачем avg-у пользовать тип, больший чем тип поля? Или трудно вычислить avg от N+1 записи, зная avg предыдущих N (размерность - та же, что и у поля), значение поля в N+1 записи (размерност ь - та же, что и поле) и само это N?

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

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

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

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

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

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

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


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

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

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

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

1
2
1
Достаточно знать еще и номер шага. А это легко реализуется композитным внутренним типом аггрегата в постгресе.
...
Рейтинг: 0 / 0
13.06.2007, 19:45
    #34593067
СергейК
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Производительность avg
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
14.06.2007, 05:29
    #34593423
ChameLe0n
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Производительность avg
Код: 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
14.06.2007, 05:41
    #34593426
ChameLe0n
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Производительность avg
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
14.06.2007, 05:51
    #34593431
ChameLe0n
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Производительность avg
СергейК
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
14.06.2007, 10:07
    #34593729
msa@n-e.ru
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Производительность avg
СергейК 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
14.06.2007, 10:18
    #34593768
st_serg
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Производительность avg
70% постов в ветке ms access обязывает :)
...
Рейтинг: 0 / 0
14.06.2007, 10:32
    #34593809
assa
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Производительность avg
Andrey DaeronНакопление ошибки ИМХО действительно будет иметь место. на каждом шагу умножение и два деления + округление.

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

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

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


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

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


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

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

Чушь несли вы
...
Рейтинг: 0 / 0
14.06.2007, 12:29
    #34594241
LeXa NalBat
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Производительность avg
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
Форумы / PostgreSQL [игнор отключен] [закрыт для гостей] / Производительность avg / 21 сообщений из 21, страница 1 из 1
Найденые пользователи ...
Разблокировать пользователей ...
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


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