powered by simpleCommunicator - 2.0.53     © 2025 Programmizd 02
Форумы / Firebird, InterBase [игнор отключен] [закрыт для гостей] / Импортозамещение - кто хочет опубликоваться в PCMagazine?
25 сообщений из 69, страница 2 из 3
Импортозамещение - кто хочет опубликоваться в PCMagazine?
    #39229333
afgm
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Симонов Денисох уж эти сравнения.
Ну раз такой оффтоп:
Вообще хорошего теста не хватает.
Я лично для себя гоняю периодически тесты MSSQL vs FB vs Pg.
По факту массовые заливки в Pg быстрее. На дефолтных настройках. В FB подкручена память сортировки и кеш.
Время создания толстых индексов сравнимое (3 поля и более, записей 100К .. 1M).
А вот интересное начинается если Update начать гонять при наличии уже построенных индексов. Вот тут FB часто начинает обгонять. Причём раза в два, если правильно помню. Начинаем мучать Pg: нелогируемая таблица, заполнение страниц уменьшаем. Начинает ускоряться, но всё равно FB по дефолту резвее бегает. К сожалению я не спец в Pg и не могу адекватно его тюнить. Так что нужен спец, крайне желательно из обоих миров.
...
Рейтинг: 0 / 0
Импортозамещение - кто хочет опубликоваться в PCMagazine?
    #39229345
Polesov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Симонов Денисох уж эти сравнения.чем богаты...

Если все параметры конфига в дефолте, то тест сразу на свалку.на свалку...

Попробуй на 3.0лениво...
...
Рейтинг: 0 / 0
Импортозамещение - кто хочет опубликоваться в PCMagazine?
    #39229353
Фотография Симонов Денис
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
PolesovЕсли все параметры конфига в дефолте, то тест сразу на свалку.на свалку...


параметра по умолчанию в FB откровенно говоря отстой рассчитаны на совсем маленькие БД.
Правда говорят что в PG тоже. Но какие выставлены лучше хз

Ты кстати не сказал в какой архитектуре пробовал.
...
Рейтинг: 0 / 0
Импортозамещение - кто хочет опубликоваться в PCMagazine?
    #39229379
Polesov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Симонов ДенисТы кстати не сказал в какой архитектуре пробовал.

Ooops... classic server
...
Рейтинг: 0 / 0
Импортозамещение - кто хочет опубликоваться в PCMagazine?
    #39229509
Фотография Alexey Kovyazin
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Не, Классик и 2.5 оригинально конечно использовать, но все таки лучше взять 3.0 SuperServer с конфигом с
http://ib-aid.com/en/optimized-firebird-configuration/
...
Рейтинг: 0 / 0
Импортозамещение - кто хочет опубликоваться в PCMagazine?
    #39231270
NikolayV81
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Polesov,

По условию задачи разве не update построчно с коммитом транзакции потом? На том железе где тестил update одним запросом был бы в несколько секунд. Я тестировал именно на то как поведёт себя оракл, при издевательствах над индексами.
6 миллионов потому что где-то в другом месте запомнилась эта цифра ( в Пятнице вроде)
...
Рейтинг: 0 / 0
Импортозамещение - кто хочет опубликоваться в PCMagazine?
    #39231287
MaratIsk
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Если все параметры конфига в дефолте, то тест сразу на свалку.

сразу видно болтуна
...
Рейтинг: 0 / 0
Импортозамещение - кто хочет опубликоваться в PCMagazine?
    #39231530
Евгений Болтик
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Не пинать. Всесторонние тесты нужны только для ориентира. И выявления узких мест. Желательно делать это на одинаковом железе. У нас сейчас будет не очень объективная картина, но есть моменты которые меня интересуют.

Объясняю почему. Когда то моя база создавалась за 30 секунд и потом произошло резкое увеличение времени создания. Сейчас создание на SSD 50 секунд. Мне было лень тогда искать причину этого, ведь у клиентов тормозов не наблюдалось. Теперь поздно.

Как только перехожу на новую версию старую не использую вообще.
Firebird-3.0.1.32510-0_Win32
Но пришлось сделать и для Fb 2.5.6.26979 т.к. результат сильно отличался Polesov

SSD чтение и запись 41Мбайт/сек было в "Монитор ресурсом"
База распухла в обоих вариантах с 1700Мб до 16Гб с индексом до 20Гб

Тройка отстает от 2.5, но надо понимать в 3-ке упор на множественные подключения и это плата за быстродействие в 1-ом коннекте. Об этом наверно и разработчики скажут.

Интересно при создании базы у меня 1.5 раза создалось быстрей чем у Polesov. НО по выборкам расхождения жуткие с Polesov. У меня зекало у Polesov наверно последовательный РАЙД.
update быстрый.

Polesov
Заполнение таблицы

FB - 19 мин 19 сек
Код: plsql
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
execute block
as
  declare variable ID integer;
begin
  ID = 0;
  while ( ID < 100000000 ) do
  begin
    ID = :ID + 1;
    insert into TEST (
        ID,
        STR_80,
        DAT,
        STR_2000 )
    values ( :ID,
             'STR_80( ' || lpad( :ID, 9, '0' ) || ' )',
             current_date,
             'STR_2000( ' || current_date || ' ) - STR_80( ' || lpad( :ID, 9, '0' ) || ' )' );
  end
end;




Fb 3.0.1.32510
Время подготовки "00:00:00.003", выполнения "00:12:37.943"
Plan:
MaxMemory: 383611736, CurrentMemory: 329672320, NumBuffers: 38192
Cache fetches 311564521, reads from disk 16, writes to disk 1854011
"RDB$PAGES" backout 0, delete 0, expunge 0, insert 1156, purge 0, read_idx 0, read_seq 0, update 0
"TEST" backout 0, delete 0, expunge 0, insert 100000000, purge 0, read_idx 0, read_seq 0, update 0
Fb 2.5.6.26979
Время подготовки "00:00:00.003", выполнения "00:12:14.375"
Plan:
MaxMemory: 372039676, CurrentMemory: 323576656, NumBuffers: 38192
Cache fetches 315100295, reads from disk 0, writes to disk 1851609
"RDB$PAGES" backout 0, delete 0, expunge 0, insert 982, purge 0, read_idx 0, read_seq 0, update 0
"TEST" backout 0, delete 0, expunge 0, insert 100000000, purge 0, read_idx 0, read_seq 0, update 0

Так сравнил разницу между системами.
19*60+19=1159
12*60+37=757
1159/757=~1.5 раза мой комп выполнил это быстрей. НО это может зависит от настроек конфига которые просили в студию
У меня они такие
Код: sql
1.
2.
3.
4.
5.
6.
DefaultDbCachePages = 38192
FileSystemCacheThreshold = 264K
GCPolicy = background
RemoteAuxPort  = 3051
ServerMode = Classic
TempDirectories = f:\



PG - 8 мин 12 сек
Код: plsql
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
DO
$$DECLARE 
  ID integer;
BEGIN
  ID = 0;
  WHILE ( ID < 100000000 ) LOOP
    ID = ID + 1;
    insert into TEST (
        ID,
        STR_80,
        DAT,
        STR_2000 )
    values (
        ID,
        'STR_80( ' || lpad( cast( ID as varchar(9) ), 9, '0' ) || ' )',
        current_date,
        'STR_2000( ' || current_date || ' ) - STR_80( ' || lpad( cast( ID as varchar(9) ), 9, '0' ) || ' )' );
  END LOOP;
END$$;



Создание индекса
Код: plsql
1.
2.
3.
4.
5.
-- FB - 6 мин 38 сек
-- PG - 2 мин 51 сек
alter table TEST
  add constraint PK_TEST
      primary key (ID,STR_80,DAT);





Fb 3.0.1.32510
4:25 соотношение времени 1.5 раза тут все в порядке
Fb 2.5.6.26979
4:55


Несколько селектов
Код: plsql
1.
2.
3.
4.
5.
-- FB - 7.72 сек
-- PG - 2.42 сек
select count(*)
  from TEST
 where ID between 1 and 10000000;



Fb 3.0.1.32510
Время подготовки "00:00:00.237", выполнения "00:00:13.400"
Plan:PLAN (TEST INDEX (PK_TEST))
MaxMemory: 538290632, CurrentMemory: 334019936, NumBuffers: 38192
Cache fetches 20048822, reads from disk 237598, writes to disk 0
"TEST" backout 0, delete 0, expunge 0, insert 0, purge 0, read_idx 10000007, read_seq 0, update 0
Fb 2.5.6.26979
Время подготовки "00:00:00.154", выполнения "00:00:10.548"
Plan:PLAN (TEST INDEX (PK_TEST))
MaxMemory: 533370408, CurrentMemory: 328532544, NumBuffers: 38192
Cache fetches 20048822, reads from disk 237581, writes to disk 5
"TEST" backout 0, delete 0, expunge 0, insert 0, purge 0, read_idx 10000007, read_seq 0, update 0

Код: plsql
1.
2.
3.
4.
5.
-- FB - 7.69 сек
-- PG - 2.11 сек
select count(*)
  from TEST
 where ID between 45000001 and 55000000;



Fb 3.0.1.32510
Время подготовки "00:00:00.003", выполнения "00:00:10.939"
Plan:PLAN (TEST INDEX (PK_TEST))
MaxMemory: 538290632, CurrentMemory: 334019376, NumBuffers: 38192
Cache fetches 20051087, reads from disk 239821, writes to disk 0
"TEST" backout 0, delete 0, expunge 0, insert 0, purge 0, read_idx 10000031, read_seq 0, update 0
Fb 2.5.6.26979
Время подготовки "00:00:00.007", выполнения "00:00:09.480"
Plan:PLAN (TEST INDEX (PK_TEST))
MaxMemory: 533370408, CurrentMemory: 328532560, NumBuffers: 38192
Cache fetches 20051087, reads from disk 239804, writes to disk 0
"TEST" backout 0, delete 0, expunge 0, insert 0, purge 0, read_idx 10000031, read_seq 0, update 0
Код: plsql
1.
2.
3.
4.
5.
-- FB - 7.67 сек
-- PG - 2.45 сек
select count(*)
  from TEST
 where ID between 99000001 and 100000000;



Fb 3.0.1.32510
Время подготовки "00:00:00.004", выполнения "00:00:01.085"
Plan:PLAN (TEST INDEX (PK_TEST))
MaxMemory: 538290632, CurrentMemory: 329164048, NumBuffers: 38192
Cache fetches 2005107, reads from disk 23988, writes to disk 0
"TEST" backout 0, delete 0, expunge 0, insert 0, purge 0, read_idx 1000000, read_seq 0, update 0
Fb 2.5.6.26979
Время подготовки "00:00:00.009", выполнения "00:00:00.988"
Plan:PLAN (TEST INDEX (PK_TEST))
MaxMemory: 533370408, CurrentMemory: 324170568, NumBuffers: 38192
Cache fetches 2005107, reads from disk 23975, writes to disk 0
"TEST" backout 0, delete 0, expunge 0, insert 0, purge 0, read_idx 1000000, read_seq 0, update 0
order by + полный фетч

Код: plsql
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
-- FB - 27.94 сек
select first(100000) skip(20000000) *
  from TEST
 where ID > 0
 order by ID, STR_80, DAT;

-- PG - 3.53 сек
select *
  from TEST
 where ID > 0
 order by ID, STR_80, DAT
limit(100000) offset(20000000);



Fb 3.0.1.32510
Время подготовки "00:00:00.009", выполнения "00:00:43.030"
Plan:PLAN (TEST ORDER PK_TEST)
MaxMemory: 538290632, CurrentMemory: 339424296, NumBuffers: 38192
Cache fetches 60102650, reads from disk 477266, writes to disk 0
"TEST" backout 0, delete 0, expunge 0, insert 0, purge 0, read_idx 20000996, read_seq 0, update 0
Fb 2.5.6.26979
Время подготовки "00:00:00.005", выполнения "00:00:44.069"
Plan:PLAN (TEST ORDER PK_TEST INDEX (PK_TEST))
MaxMemory: 533370408, CurrentMemory: 381843796, NumBuffers: 38192
Cache fetches 60607742, reads from disk 985030, writes to disk 0
"TEST" backout 0, delete 0, expunge 0, insert 0, purge 0, read_idx 20000088, read_seq 0, update 0
Код: plsql
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
-- FB - 26.18 сек
select first(100000) skip(20000000) *
  from TEST
 where ID > 30000000
 order by ID, STR_80, DAT;

-- PG - 32.14 сек
select *
  from TEST
 where ID > 30000000
 order by ID, STR_80, DAT
limit(100000) offset(20000000);



Fb 3.0.1.32510
Время подготовки "00:00:00.005", выполнения "00:00:54.328"
Plan:PLAN (TEST ORDER PK_TEST)
MaxMemory: 538290632, CurrentMemory: 339424312, NumBuffers: 38192
Cache fetches 60105041, reads from disk 479659, writes to disk 0
"TEST" backout 0, delete 0, expunge 0, insert 0, purge 0, read_idx 20000997, read_seq 0, update 0
Fb 2.5.6.26979
Время подготовки "00:00:00.008", выполнения "00:00:45.121"
Plan:PLAN (TEST ORDER PK_TEST INDEX (PK_TEST))
MaxMemory: 533370408, CurrentMemory: 367308440, NumBuffers: 38192
Cache fetches 60459460, reads from disk 836750, writes to disk 0
"TEST" backout 0, delete 0, expunge 0, insert 0, purge 0, read_idx 20000089, read_seq 0, update 0
Код: plsql
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
-- FB - 25.26 сек
select first(100000) skip(20000000) *
  from TEST
 where ID > 79000000
 order by ID, STR_80, DAT;

-- PG - 13.76 сек
select *
  from TEST
 where ID > 79000000
 order by ID, STR_80, DAT
limit(100000) offset(20000000);



Fb 3.0.1.32510
Время подготовки "00:00:00.004", выполнения "00:00:54.452"
Plan:PLAN (TEST ORDER PK_TEST)
MaxMemory: 538290632, CurrentMemory: 339424312, NumBuffers: 38192
Cache fetches 60105041, reads from disk 479659, writes to disk 0
"TEST" backout 0, delete 0, expunge 0, insert 0, purge 0, read_idx 20000997, read_seq 0, update 0
Fb 2.5.6.26979
Время подготовки "00:00:00.009", выполнения "00:00:43.058"
Plan:PLAN (TEST ORDER PK_TEST INDEX (PK_TEST))
MaxMemory: 533370408, CurrentMemory: 343564628, NumBuffers: 38192
Cache fetches 60209460, reads from disk 586750, writes to disk 0
"TEST" backout 0, delete 0, expunge 0, insert 0, purge 0, read_idx 20000089, read_seq 0, update 0
Непонятно, почему для PG такой разброс: 3.53 - 32.14 - 13.76


Вообще ничего не понимаю. Чувствую надо будет для FB2 тест проверить.
update
Код: plsql
1.
2.
3.
4.
5.
-- FB - 2 мин 43 сек
-- PG - 3 мин 53 сек
update TEST
   set STR_2000 = STR_2000 || STR_2000
 where ID between 45000001 and 55000000;



Fb 3.0.1.32510
Время подготовки "00:00:00.007", выполнения "00:02:10.892"
Plan:PLAN (TEST INDEX (PK_TEST))
MaxMemory: 538290632, CurrentMemory: 336000864, NumBuffers: 38192
Cache fetches 136096383, reads from disk 241012, writes to disk 241523
"RDB$PAGES" backout 0, delete 0, expunge 0, insert 55, purge 0, read_idx 0, read_seq 0, update 0
"RDB$RELATION_CONSTRAINTS" backout 0, delete 0, expunge 0, insert 0, purge 0, read_idx 0, read_seq 1410, update 0
"RDB$INDICES" backout 0, delete 0, expunge 0, insert 0, purge 0, read_idx 1640, read_seq 1696, update 0
"TEST" backout 0, delete 0, expunge 0, insert 0, purge 0, read_idx 10000031, read_seq 0, update 10000000
Fb 2.5.6.26979
Время подготовки "00:00:00.008", выполнения "00:01:53.063"
Plan:PLAN (TEST INDEX (PK_TEST))
MaxMemory: 533370408, CurrentMemory: 329754040, NumBuffers: 38192
Cache fetches 150208860, reads from disk 239826, writes to disk 241484
"RDB$PAGES" backout 0, delete 0, expunge 0, insert 47, purge 0, read_idx 0, read_seq 0, update 0
"RDB$INDICES" backout 0, delete 0, expunge 0, insert 0, purge 0, read_idx 2, read_seq 0, update 0
"TEST" backout 0, delete 0, expunge 0, insert 0, purge 0, read_idx 10000031, read_seq 0, update 10000000

P.S. Компьютер один и тот же, диск один и тот же, оба сервера 32-х битные.
...
Рейтинг: 0 / 0
Импортозамещение - кто хочет опубликоваться в PCMagazine?
    #39231605
Фотография Симонов Денис
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
MaratIskЕсли все параметры конфига в дефолте, то тест сразу на свалку.

сразу видно болтуна

ага, то есть ты считаешь что 75 страниц кеша и 8M под сортировку это нормально.
А ещё и размер страницы небось 4K был.
...
Рейтинг: 0 / 0
Импортозамещение - кто хочет опубликоваться в PCMagazine?
    #39231607
Фотография Симонов Денис
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Евгений БолтикDefaultDbCachePages = 38192
FileSystemCacheThreshold = 264K
GCPolicy = background
RemoteAuxPort = 3051
ServerMode = Classic
TempDirectories = f:\

на классике такой огромный кеш вреден. Хотя тест тут в один поток идёт, так что никак не сказывается.
Какой ещё background на классике? Почему не супер?

TempCacheLimit не увеличивал хотя бы до гигабайта? Это должно улучшить время создания индекса и скорость сортировок
...
Рейтинг: 0 / 0
Импортозамещение - кто хочет опубликоваться в PCMagazine?
    #39231681
MaratIsk
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Симонов ДенисMaratIskпропущено...


сразу видно болтуна

ага, то есть ты считаешь что 75 страниц кеша и 8M под сортировку это нормально.
А ещё и размер страницы небось 4K был.

тест должен строиться на дефолтовых параметрах, исходя из того, что разработчик предусмотрел их как оптимальные для типичного применения

есть, разумеется, кудесники знающие все закоулки субд, но таковых немного и погоды в массе они не делают
...
Рейтинг: 0 / 0
Импортозамещение - кто хочет опубликоваться в PCMagazine?
    #39231688
miwaonline
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
MaratIskСимонов Дениспропущено...


ага, то есть ты считаешь что 75 страниц кеша и 8M под сортировку это нормально.
А ещё и размер страницы небось 4K был.

тест должен строиться на дефолтовых параметрах, исходя из того, что разработчик предусмотрел их как оптимальные для типичного применения

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

А вообще, предлагаю уже заодно делать тест на 256МБ ОЗУ и позвать мускуль с оракулом. «Для себя, чисто поржать»©
...
Рейтинг: 0 / 0
Импортозамещение - кто хочет опубликоваться в PCMagazine?
    #39231733
Polesov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Я очень дико извиняюсь

В этом месте всралась ачипятка:
Код: plsql
1.
2.
3.
select count(*)
  from TEST
 where ID between 99000001 and 100000000;



Не 99000001 , а 90000001 - count считался по 10 млн записей
Код: plsql
1.
2.
3.
select count(*)
  from TEST
where ID between 90000001 and 100000000;



Цифры приведены для 90000001
Код: plsql
1.
2.
-- FB - 7.67 сек
-- PG - 2.45 сек
...
Рейтинг: 0 / 0
Импортозамещение - кто хочет опубликоваться в PCMagazine?
    #39231738
Polesov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
NikolayV81По условию задачи разве не update построчно с коммитом транзакции потом?


Ну, смотря что понимать под массовым апдейтом, изначально уточнено не было.
Alexey Kovyazinна таблице ID, varchar(80), date, varchar(2000), с индексами по ID, varchar(80), date, таблица 100 млн записей (сгенерить надо), пропадейтить 10 миллионов.
...
Рейтинг: 0 / 0
Импортозамещение - кто хочет опубликоваться в PCMagazine?
    #39231824
NikolayV81
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
PolesovNikolayV81По условию задачи разве не update построчно с коммитом транзакции потом?


Ну, смотря что понимать под массовым апдейтом, изначально уточнено не было.
Alexey Kovyazinна таблице ID, varchar(80), date, varchar(2000), с индексами по ID, varchar(80), date, таблица 100 млн записей (сгенерить надо), пропадейтить 10 миллионов.
Если не ошибаюсь где-то проскакивала тема про данное приложение и про макс. размер тела запроса в 3ке да и ещё если посмотреть на мой пример там идёт обновление именно полей входящих в индекс (что собственно для оракла и критично из-за чего в etl и стараются избегать constraint-ов , либо отключают / включают их при заливках ).
...
Рейтинг: 0 / 0
Импортозамещение - кто хочет опубликоваться в PCMagazine?
    #39232165
Фотография kdv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
MaratIskтест должен строиться на дефолтовых параметрах
давно известно, что много дефолтных параметров ФБ идут со времен царя гороха, и уже давно неактуальны. Даже для суперсервера размер кэша в 2000 страниц - это мизерабль.
Так что ваш выстрел про "болтуна" на самом деле вам в ногу.
...
Рейтинг: 0 / 0
Импортозамещение - кто хочет опубликоваться в PCMagazine?
    #39232217
Polesov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
NikolayV81если посмотреть на мой пример там идёт обновление именно полей входящих в индексНу, я исходил из того, что менять значения полей, входящих в первичный индекс, как-то не комильфо.

А вообще, при такой постановке задачи всяк интерпретирует ее по своему.
...
Рейтинг: 0 / 0
Импортозамещение - кто хочет опубликоваться в PCMagazine?
    #39232222
Фотография Симонов Денис
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Polesov,

не комильфо вообще такой PK делать. Разве что для теста в равных условиях.

ИХМО весь хвост топика про тестирование надо бы в отдельную тему оформить
...
Рейтинг: 0 / 0
Импортозамещение - кто хочет опубликоваться в PCMagazine?
    #39232239
MaratIsk
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
kdvMaratIskтест должен строиться на дефолтовых параметрах
давно известно, что много дефолтных параметров ФБ идут со времен царя гороха, и уже давно неактуальны. Даже для суперсервера размер кэша в 2000 страниц - это мизерабль.
Так что ваш выстрел про "болтуна" на самом деле вам в ногу.

ну можно же дефолты в документации к релизу указывать
...
Рейтинг: 0 / 0
Импортозамещение - кто хочет опубликоваться в PCMagazine?
    #39232242
MaratIsk
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
MaratIskkdvпропущено...

давно известно, что много дефолтных параметров ФБ идут со времен царя гороха, и уже давно неактуальны. Даже для суперсервера размер кэша в 2000 страниц - это мизерабль.
Так что ваш выстрел про "болтуна" на самом деле вам в ногу.

ну можно же дефолты в документации к релизу указывать

хрен с ним с историческими слоями кода - понимаю, перелопачивать их тоска смертная
...
Рейтинг: 0 / 0
Импортозамещение - кто хочет опубликоваться в PCMagazine?
    #39232244
afgm
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Симонов ДенисИХМО весь хвост топика про тестирование надо бы в отдельную тему оформить
Согласен. И не в "Сравнение СУБД", а оставить тут, потому как там он сгинет.
...
Рейтинг: 0 / 0
Импортозамещение - кто хочет опубликоваться в PCMagazine?
    #39232252
Polesov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Симонов Денисне комильфо вообще такой PK делатьНу, таково было условие от Alexey Kovyazin .

Симонов ДенисИХМО весь хвост топика про тестирование надо бы в отдельную тему оформитьДа уже нет смысла, кмк (в силу некорректной постановки задачи).

Странный разброс по времени выполнения запросов с полным фетчем на PG. Видимо, надо будет в профильной спросить.

Удивило, что по результатам тестирования Евгений Болтик FB3.0 был медленнее в селектах, чем 2.5.
Он сказал, что тестировал на SSD, у меня же обычный SATA.
...
Рейтинг: 0 / 0
Импортозамещение - кто хочет опубликоваться в PCMagazine?
    #39232263
Фотография Симонов Денис
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
PolesovСимонов Денисне комильфо вообще такой PK делатьНу, таково было условие от Alexey Kovyazin .


не уверен в этом.

Alexey KovyazinУ кого Оракл под рукой, проверьте пожалуйста на таблице ID, varchar(80), date, varchar(2000), с индексами по ID, varchar(80), date, таблица 100 млн записей (сгенерить надо), пропадейтить 10 миллионов.

подозреваю что тут не один общий индекс (PK), а по индексу на каждое поле. И это может в некоторых случаях весьма сильно изменить результат.
...
Рейтинг: 0 / 0
Импортозамещение - кто хочет опубликоваться в PCMagazine?
    #39232265
Polesov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Симонов ДенисPolesovпропущено...
Ну, таково было условие от Alexey Kovyazin .

не уверен в этом.

Ну, значит я не правильно понял
...
Рейтинг: 0 / 0
Импортозамещение - кто хочет опубликоваться в PCMagazine?
    #39232297
Фотография Симонов Денис
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
PolesovСтранный разброс по времени выполнения запросов с полным фетчем на PG.

само по себе тестирование полного фетча имеет множество нюансов.

1. Полный фетч он ещё учитывает затраты сетевого протокола
2. Вопрос как и где он проводился. Если в IBexpert и pgadmin, то надо учитывать, что там ещё неизвестно сколько вносят компоненты доступа. Плюс в IBE сам грид навороченный, отображение всех записей в нём имеет весьма существенные затраты.

PolesovУдивило, что по результатам тестирования Евгений Болтик FB3.0 был медленнее в селектах, чем 2.5.

конфиг у Болтика весьма странный. Кэш в FB 3.0 на одном потоке чуть медленней чем в 2.5.
...
Рейтинг: 0 / 0
25 сообщений из 69, страница 2 из 3
Форумы / Firebird, InterBase [игнор отключен] [закрыт для гостей] / Импортозамещение - кто хочет опубликоваться в PCMagazine?
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Найденые пользователи ...
Разблокировать пользователей ...
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


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