ReSQL.ru
     
powered by simpleCommunicator - 2.0.61     © 2026 Programmizd 02
Мобильная версия    Контакт    Правила    FAQ    Помощь
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Доб. в избранное | Игнор. тему | Прикреп. тему | Пометить прочит. / непрочит. | Фильтр
Форумы / Firebird, InterBase [игнор отключен] [закрыт для гостей] / gstat -r, статистика по PK-индексу: total dup >> 0, max dup =2..3 Как это может быть ?
25 сообщений из 29, страница 1 из 2
  1  все
gstat -r, статистика по PK-индексу: total dup >> 0, max dup =2..3 Как это может быть ?
    #38689940
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Таблоид
Участник
hi all

Допустим, есть вот такие две таблички:
Код: sql
1.
2.
3.
4.
5.
6.
7.
8.
9.
recreate table qdistr(
   id dm_ids generated by default as identity constraint pk_qdistr primary key using index pk_qdistr
   . . . other fields . . .
);

recreate table qstorned(
   id dm_ids constraint pk_qdstorned primary key using index pk_qdstorned
   . . . other fields . . .
);

Данные сначала всегда попадают в первую из них. При этом поле id монотонно увеличивается (см DDL).
В процессе работы некоторые записи могут быть перемещены из qdistr в qstorned (т.е. с удалением в первой). Затем они могут быть перемещены обратно. При таком "обратном" движении (из qstorned в pdistr) значение в поле ID сохраняется - его всё равно не будет в приемнике ввиду предыдущего удаления оттудова.

До начала любого вида перемещения выполняется попытка блокировки выбранной записи в таблице-источнике, дабы бестолку не вызывать insert в таблице-приёмнике. Из этого следует, что сколько бы транзакций-конкурентов не трудилось одновременно, бубликатов в первичном ключе не будет (ни в одной из таблиц).

Тогда как объяснить результат gstat -r для этих табличек:
 
Код: 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.
27.
28.
29.
30.
31.
32.
33.
34.
35.
36.
37.
38.
39.
40.
41.
42.
43.
44.
45.
46.
47.
48.
49.
50.
51.
52.
53.
54.
55.
56.
57.
58.
59.
60.
61.
62.
63.
64.
65.
66.
67.
68.
69.
70.
71.
72.
73.
74.
75.
76.
77.
78.
79.
80.
81.
82.
83.
84.
85.
86.
87.
88.
89.
90.
91.
92.
93.
94.
95.
96.
97.
98.
99.
100.
101.
102.
103.
104.
105.
106.
107.
108.
109.
110.
111.
112.
113.
114.
115.
116.
117.
118.
119.
120.
121.
122.
123.
124.
125.
126.
127.
128.
129.
130.
131.
132.
133.
134.
135.
136.
137.
138.
139.
140.
141.
142.
143.
144.
145.
146.
147.
148.
149.
QDISTR (151)
    Primary pointer page: 239, Index root page: 240
    Total formats: 1, used formats: 1
    Average record length: 64.25, total records: 4780985
    Average version length: 51.09, total versions: 435633, max versions: 4
    Average fragment length: 57.50, total fragments: 2, max fragments: 1
    Average unpacked length: 128.00, compression ratio: 1.99
    Pointer pages: 11, data page slots: 37537
    Data pages: 37483, average fill: 69%
    Primary pages: 37278, full pages: 16846, swept pages: 11706
    Fill distribution:
	 0 - 19% = 212
	20 - 39% = 255
	40 - 59% = 5340
	60 - 79% = 31435
	80 - 99% = 241

    Index PK_QDISTR (0)
	Root page: 18778, depth: 3, leaf buckets: 5827, nodes: 4780985
	Average node length: 11.53,  total dup: 2360, max dup: 3  <<<<<<<<<<<<<< [ 1 ] <<<<<<<<<<<<<
	Average key length: 8.55, compression ratio: 1.05
	Average prefix length: 3.45, average data length: 5.55
	Clustering factor: 744689, ratio: 0.16
	Fill distribution:
	     0 - 19% = 215
	    20 - 39% = 1130
	    40 - 59% = 2382
	    60 - 79% = 390
	    80 - 99% = 1710

    Index QDISTR_DOC_SND (3)
	Root page: 15991, depth: 3, leaf buckets: 2959, nodes: 4780985
	Average node length: 6.10, total dup: 4327928, max dup: 90
	Average key length: 3.11, compression ratio: 8.68
	Average prefix length: 25.98, average data length: 1.02
	Clustering factor: 2932562, ratio: 0.61
	Fill distribution:
	     0 - 19% = 22
	    20 - 39% = 358
	    40 - 59% = 1124
	    60 - 79% = 724
	    80 - 99% = 731

    Index QDISTR_ID_DESC (4)
	Root page: 15052, depth: 3, leaf buckets: 7648, nodes: 4780985
	Average node length: 11.53, total dup: 2360, max dup: 3
	Average key length: 8.55, compression ratio: 1.05
	Average prefix length: 3.45, average data length: 5.55
	Clustering factor: 744725, ratio: 0.16
	Fill distribution:
	     0 - 19% = 2
	    20 - 39% = 1812
	    40 - 59% = 5782
	    60 - 79% = 39
	    80 - 99% = 13

    Index QDISTR_SND_ID (2)
	Root page: 28666, depth: 3, leaf buckets: 3498, nodes: 4780985
	Average node length: 5.66, total dup: 4327928, max dup: 90
	Average key length: 2.67, compression ratio: 3.37
	Average prefix length: 8.42, average data length: 0.58
	Clustering factor: 2938598, ratio: 0.61
	Fill distribution:
	     0 - 19% = 26
	    20 - 39% = 651
	    40 - 59% = 2434
	    60 - 79% = 359
	    80 - 99% = 28

    Index QDISTR_WARE_SND_OPTYPE (1)
	Root page: 21748, depth: 3, leaf buckets: 2890, nodes: 4802188
	Average node length: 5.01, total dup: 4798781, max dup: 7421
	Average key length: 2.03, compression ratio: 13.33
	Average prefix length: 26.97, average data length: 0.03
	Clustering factor: 2838778, ratio: 0.59
	Fill distribution:
	     0 - 19% = 7
	    20 - 39% = 153
	    40 - 59% = 2259
	    60 - 79% = 323
	    80 - 99% = 148

QSTORNED (152)
    Primary pointer page: 241, Index root page: 242
    Total formats: 1, used formats: 1
    Average record length: 70.92, total records: 794944
    Average version length: 71.15, total versions: 13779, max versions: 1
    Average fragment length: 60.14, total fragments: 7, max fragments: 1
    Average unpacked length: 128.00, compression ratio: 1.80
    Pointer pages: 2, data page slots: 5644
    Data pages: 5643, average fill: 77%
    Primary pages: 5641, full pages: 4411, swept pages: 3751
    Fill distribution:
	 0 - 19% = 2
	20 - 39% = 4
	40 - 59% = 111
	60 - 79% = 3239
	80 - 99% = 2287

    Index PK_QDSTORNED (0)
	Root page: 550, depth: 2, leaf buckets: 883, nodes: 794944
	Average node length: 11.89,  total dup: 6169, max dup: 2   <<<<<<<<<<<<<< [ 2 ] <<<<<<<<<<<<<
	Average key length: 8.99, compression ratio: 1.00
	Average prefix length: 3.00, average data length: 6.00
	Clustering factor: 710396, ratio: 0.89
	Fill distribution:
	     0 - 19% = 2
	    20 - 39% = 0
	    40 - 59% = 347
	    60 - 79% = 370
	    80 - 99% = 164

    Index QSTORNED_DOC_ID (1)
	Root page: 872, depth: 2, leaf buckets: 390, nodes: 794944
	Average node length: 5.11, total dup: 773596, max dup: 3633
	Average key length: 2.21, compression ratio: 4.07
	Average prefix length: 8.82, average data length: 0.18
	Clustering factor: 144666, ratio: 0.18
	Fill distribution:
	     0 - 19% = 0
	    20 - 39% = 5
	    40 - 59% = 179
	    60 - 79% = 130
	    80 - 99% = 76

    Index QSTORNED_RCV_ID (3)
	Root page: 907, depth: 2, leaf buckets: 446, nodes: 794944
	Average node length: 5.20, total dup: 753956, max dup: 64103
	Average key length: 2.30, compression ratio: 3.59
	Average prefix length: 7.94, average data length: 0.33
	Clustering factor: 61537, ratio: 0.08
	Fill distribution:
	     0 - 19% = 15
	    20 - 39% = 21
	    40 - 59% = 245
	    60 - 79% = 112
	    80 - 99% = 53

    Index QSTORNED_SND_ID (2)
	Root page: 854, depth: 2, leaf buckets: 437, nodes: 794944
	Average node length: 5.73, total dup: 704798, max dup: 108
	Average key length: 2.83, compression ratio: 3.17
	Average prefix length: 8.28, average data length: 0.72
	Clustering factor: 169008, ratio: 0.21
	Fill distribution:
	     0 - 19% = 1
	    20 - 39% = 1
	    40 - 59% = 195
	    60 - 79% = 165
	    80 - 99% = 75

PS. И еще вопрос, вернее - просьба.
2 dimitr / hvlad : я правильно понимаю (перечитав топег про clustering factor ), что если разделить число `nodes` на число `Clustering factor`, то результат будет говорить, насколько часто происходит random IO при выполнении навигации по данному индексу (plan order ...) ?
Например, для вот этого:
Код: plaintext
1.
2.
3.
4.
5.
    Index QDISTR_DOC_SND (3)
	Root page: 15991, depth: 3, leaf buckets: 2959, nodes:  4780985 
	Average node length: 6.10, total dup: 4327928, max dup: 90
	Average key length: 3.11, compression ratio: 8.68
	Average prefix length: 25.98, average data length: 1.02
	Clustering factor:  2932562 , ratio: 0.61
- получаем 4780985 / 2932562 = ~1.6, т.е. для это ~5/3.
Для каждых 5 ключей будет 3 скачка со страницы на страницу - правильно ?

PPS. Что такое "ratio", рядом с фактором кластеризации ?
...
Рейтинг: 0 / 0
08.07.2014, 01:58
| Ответить | Цитировать | Написать  
gstat -r, статистика по PK-индексу: total dup >> 0, max dup =2..3 Как это может быть ?
    #38689967
dimitr
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
dimitr
Участник
Таблоидя правильно понимаю что если разделить число `nodes` на число `Clustering factor`, то результат будет говорить, насколько часто происходит random IO при выполнении навигации по данному индексу (plan order ...) ?
PPS. Что такое "ratio", рядом с фактором кластеризации ?
правильно. Но делить необязательно, ratio это уже результат деления (только обратный от твоего) - каждый 1.6-й ключ будет скачек на другую страницу.
...
Рейтинг: 0 / 0
08.07.2014, 07:06
| Ответить | Цитировать | Написать  
gstat -r, статистика по PK-индексу: total dup >> 0, max dup =2..3 Как это может быть ?
    #38689970
dimitr
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
dimitr
Участник
т.е. ratio это просто фактор отнесенный к числу ключей (иными словами, вынесенный в диапазон 0-1)
...
Рейтинг: 0 / 0
08.07.2014, 07:13
| Ответить | Цитировать | Написать  
gstat -r, статистика по PK-индексу: total dup >> 0, max dup =2..3 Как это может быть ?
    #38689974
dimitr
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
dimitr
Участник
еще уточню, что будет или нет random I/O также зависит от кеша, фактор кластеризации это не учитывает. Т.е. фактор скорее показывает, какая процентная часть page reads может оказаться случайной.
...
Рейтинг: 0 / 0
08.07.2014, 07:22
| Ответить | Цитировать | Написать  
gstat -r, статистика по PK-индексу: total dup >> 0, max dup =2..3 Как это может быть ?
    #38690027
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Таблоид
Участник
dimitrфактор скорее показывает, какая процентная часть page reads может оказаться случайной.Значит, чем меньше ratio, тем реже будут перепрыгивания на другую страницу, т.е. - тем лучше. Ок.
dimitrеще уточню, что будет или нет random I/O также зависит от кеша , фактор кластеризации это не учитывает.Я правильно понимать, что если страничный кеш задан с большим запасом и read(s) по данным трейса отсутствуют, а write(s) - не очень значительные (1-2 сотни), то можно считать, что random'ного IO - нету.
Или он всё таки есть, но это уже когда операционка пишет в фоновом режиме на диск, и тут нужно анализировать статистику оси, а не ФБ-трейс ?

PS. Ну, и по сабжу хотелось бы понять, как такое может быть...
...
Рейтинг: 0 / 0
08.07.2014, 09:18
| Ответить | Цитировать | Написать  
gstat -r, статистика по PK-индексу: total dup >> 0, max dup =2..3 Как это может быть ?
    #38690073
dimitr
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
dimitr
Участник
ТаблоидЯ правильно понимать, что если страничный кеш задан с большим запасом и read(s) по данным трейса отсутствуют, а write(s) - не очень значительные (1-2 сотни), то можно считать, что random'ного IO - нету.
если пара сотен возможно рандомных записей тебе незначительны, то можешь считать :-) Кластер факторизации отражает только чтения, если reads нулевой то фактор полезной информации не дает. Вот только в реальной жизни это скорее исключение.
...
Рейтинг: 0 / 0
08.07.2014, 10:10
| Ответить | Цитировать | Написать  
gstat -r, статистика по PK-индексу: total dup >> 0, max dup =2..3 Как это может быть ?
    #38690339
hvlad
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
hvlad
Участник
ТаблоидТогда как объяснить результат gstat -r для этих табличек:
Таблоид
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
QDISTR (151)
    Primary pointer page: 239, Index root page: 240
    Total formats: 1, used formats: 1
    Average record length: 64.25, total records: 4780985
    Average version length: 51.09,  total versions: 435633, max versions: 4 
    Average fragment length: 57.50, total fragments: 2, max fragments: 1
...
    Index PK_QDISTR (0)
	Root page: 18778, depth: 3, leaf buckets: 5827, nodes: 4780985
	Average node length: 11.53,  total dup: 2360, max dup: 3  <<<<<<<<<<<<<< [ 1 ] <<<<<<<<<<<<<

Мусор собирать не пробовал ? :)
...
Рейтинг: 0 / 0
08.07.2014, 13:09
| Ответить | Цитировать | Написать  
gstat -r, статистика по PK-индексу: total dup >> 0, max dup =2..3 Как это может быть ?
    #38690363
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Таблоид
Участник
hvladМусор собирать не пробовал ? :)Собрал - помогло :-)
Только всё равно не догоняю, откудова могли взяться версии (=значения) одних и тех же ID'шников, которые генератором дёргаются.
...
Рейтинг: 0 / 0
08.07.2014, 13:24
| Ответить | Цитировать | Написать  
gstat -r, статистика по PK-индексу: total dup >> 0, max dup =2..3 Как это может быть ?
    #38690452
Фотография Симонов Денис
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Симонов Денис
Участник
Таблоид,

select ... with lock тоже создаёт версии
...
Рейтинг: 0 / 0
08.07.2014, 14:12
| Ответить | Цитировать | Написать  
gstat -r, статистика по PK-индексу: total dup >> 0, max dup =2..3 Как это может быть ?
    #38690464
dimitr
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
dimitr
Участник
Симонов Денис,

но не в индексах
...
Рейтинг: 0 / 0
08.07.2014, 14:20
| Ответить | Цитировать | Написать  
gstat -r, статистика по PK-индексу: total dup >> 0, max dup =2..3 Как это может быть ?
    #38690574
Dimitry Sibiryakov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Dimitry Sibiryakov
Участник
Таблоидоткудова могли взяться версии (=значения) одних и тех же ID'шников, которые
генератором дёргаются.
Удалили запись, но мусор не собрали - нода в индексе осталась.
Вставили снова эту же запись - в индексе уже две ноды с одним значением.
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
08.07.2014, 15:09
| Ответить | Цитировать | Написать  
gstat -r, статистика по PK-индексу: total dup >> 0, max dup =2..3 Как это может быть ?
    #38690591
hvlad
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
hvlad
Участник
ТаблоидТолько всё равно не догоняю, откудова могли взяться версии (=значения) одних и тех же ID'шников, которые генератором дёргаются.А вот это кто писал ?
ТаблоидВ процессе работы некоторые записи могут быть перемещены из qdistr в qstorned (т.е. с удалением в первой). Затем они могут быть перемещены обратно. При таком "обратном" движении (из qstorned в pdistr) значение в поле ID сохраняется - его всё равно не будет в приемнике ввиду предыдущего удаления оттудова.
...
Рейтинг: 0 / 0
08.07.2014, 15:20
| Ответить | Цитировать | Написать  
gstat -r, статистика по PK-индексу: total dup >> 0, max dup =2..3 Как это может быть ?
    #38690629
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Таблоид
Участник
hvladТаблоидТолько всё равно не догоняю, откудова могли взяться версии (=значения) одних и тех же ID'шников, которые генератором дёргаются.А вот это кто писал ?
ТаблоидВ процессе работы некоторые записи могут быть перемещены из qdistr в qstorned (т.е. с удалением в первой). Затем они могут быть перемещены обратно. При таком "обратном" движении (из qstorned в pdistr) значение в поле ID сохраняется - его всё равно не будет в приемнике ввиду предыдущего удаления оттудова.А тогда у мну претензии к фоновому сборщику! Чё он не удаляет-то их при вот таком раскладе счетчиков :
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
Database "/var/db/fb30/oltp30.page16k.after3hr.200attaches_runcase08x4.fdb"
Database header page information:
        Flags                   0
        Generation              529587
        System Change Number    0
        Page size               16384
        ODS version             12.0
        Oldest transaction      529194
        Oldest active           529195
         Oldest snapshot         529193 
         Next transaction        529199 
        Sequence number         0
        Next attachment ID      955
        Implementation          HW=AMD/Intel/x64 little-endian OS=Linux CC=gcc
        Shadow count            0
        Page buffers            0
        Next header page        0
        Database dialect        3
        Creation date           Jul 7, 2014 22:00:30
        Attributes

    Variable header data:
        *END*

(это база, которая была до сборки мусора)
...
Рейтинг: 0 / 0
08.07.2014, 15:33
| Ответить | Цитировать | Написать  
gstat -r, статистика по PK-индексу: total dup >> 0, max dup =2..3 Как это может быть ?
    #38690720
hvlad
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
hvlad
Участник
ТаблоидА тогда у мну претензии к фоновому сборщику!Последний insert\delete в какой тр-ции был ? Новая тр-ция потом была ? А она сдвинула OST? А полный дисконнект был ?
...
Рейтинг: 0 / 0
08.07.2014, 16:05
| Ответить | Цитировать | Написать  
gstat -r, статистика по PK-индексу: total dup >> 0, max dup =2..3 Как это может быть ?
    #38690764
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Таблоид
Участник
hvladТаблоидА тогда у мну претензии к фоновому сборщику!Последний insert\delete в какой тр-ции был ? Новая тр-ция потом была ? А она сдвинула OST? А полный дисконнект был ?
Код: plaintext
1.
2.
3.
4.
SQL> select max(trn_id) from qdistr;

                  MAX
=====================
               528385
(это номер последней транзакции, добавлявшей запись в QDISTR)

Код: plaintext
1.
2.
3.
4.
SQL> select max(trn_id) from qstorned;

                  MAX
=====================
               528296
(это - номер транзакции, УДАЛЯВШЕЙ запись из QDISTR'a, т.к. она же добавляла её в QSTORNED; таков алгоритм).

==> новых транзакций после этого было больше тысячи.
И они, надо полагать, сдвигали OST, он же стал в итоге = 529193.
Полного дисконнекта не было, молотилки были просто остановлены (все "самозавершились" нефорсированными роллбаками).
А что, нужен был еще и полный дисконнект ?
...
Рейтинг: 0 / 0
08.07.2014, 16:26
| Ответить | Цитировать | Написать  
gstat -r, статистика по PK-индексу: total dup >> 0, max dup =2..3 Как это может быть ?
    #38690817
hvlad
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
hvlad
Участник
ТаблоидИ они, надо полагать, сдвигали OST, он же стал в итоге = 529193.Ну так он мог таким стать совсем не сразу.
ТаблоидА что, нужен был еще и полный дисконнект ?Как раз полный дисконнект не даёт шансов поработать фоновому сборщику и сбрасывает накопленную им инф-цию.
...
Рейтинг: 0 / 0
08.07.2014, 16:46
| Ответить | Цитировать | Написать  
gstat -r, статистика по PK-индексу: total dup >> 0, max dup =2..3 Как это может быть ?
    #38690844
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Таблоид
Участник
А такой вопрос: свип в 3.х - он ведь должен гораздо быстрее работать, чем в 2.х ? Ибо "заранее знает", в каких страницах мусор есть и сразу туда лезет - так или нет ?
(я к тому, что если так, то поставлю gfix -h 1000 - и "пущай полетает", вдруг попустит :))
...
Рейтинг: 0 / 0
08.07.2014, 16:58
| Ответить | Цитировать | Написать  
gstat -r, статистика по PK-индексу: total dup >> 0, max dup =2..3 Как это может быть ?
    #38690875
hvlad
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
hvlad
Участник
ТаблоидА такой вопрос: свип в 3.х - он ведь должен гораздо быстрее работать, чем в 2.х ?Не должен, а может. Чувствуешь разницу ?
...
Рейтинг: 0 / 0
08.07.2014, 17:19
| Ответить | Цитировать | Написать  
gstat -r, статистика по PK-индексу: total dup >> 0, max dup =2..3 Как это может быть ?
    #38690899
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Таблоид
Участник
hvladТаблоидА такой вопрос: свип в 3.х - он ведь должен гораздо быстрее работать, чем в 2.х ?Не должен, а может. Чувствуешь разницу ?Что-то не очень чую... Что значит "может" и при каких обст-вах "не сможет" ?
Вот, к примеру, nbackup - вон какой шустрый стал в 3.х, загляденье просто. Лопатит только изменённые страницы вместо всей базы.
А свип что же ?
...
Рейтинг: 0 / 0
08.07.2014, 17:38
| Ответить | Цитировать | Написать  
gstat -r, статистика по PK-индексу: total dup >> 0, max dup =2..3 Как это может быть ?
    #38690912
Фотография Симонов Денис
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Симонов Денис
Участник
Таблоид,

ты sweep со сборкой мусора не путай. sweep однозначно должен быть быстрее.
...
Рейтинг: 0 / 0
08.07.2014, 17:45
| Ответить | Цитировать | Написать  
gstat -r, статистика по PK-индексу: total dup >> 0, max dup =2..3 Как это может быть ?
    #38690915
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Таблоид
Участник
Симонов Денисты sweep со сборкой мусора не путай. sweep однозначно должен быть быстрее.быстрее, чем ЧТО ? чем фоновый сборщик ?
...
Рейтинг: 0 / 0
08.07.2014, 17:48
| Ответить | Цитировать | Написать  
gstat -r, статистика по PK-индексу: total dup >> 0, max dup =2..3 Как это может быть ?
    #38691013
Гаджимурадов Рустам
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гаджимурадов Рустам
Участник
Чем грузины. Смешной топик, ей-Богу.
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
08.07.2014, 18:48
| Ответить | Цитировать | Написать  
gstat -r, статистика по PK-индексу: total dup >> 0, max dup =2..3 Как это может быть ?
    #38691081
Фотография Симонов Денис
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Симонов Денис
Участник
Таблоид,

чем sweep в 2.5 конечно.
...
Рейтинг: 0 / 0
08.07.2014, 20:00
| Ответить | Цитировать | Написать  
gstat -r, статистика по PK-индексу: total dup >> 0, max dup =2..3 Как это может быть ?
    #38691103
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Таблоид
Участник
Симонов Денисчем sweep в 2.5 конечно.я из этого:авторты sweep со сборкой мусора не путай- подумкал, что ты говоришь про другое.
...
Рейтинг: 0 / 0
08.07.2014, 20:25
| Ответить | Цитировать | Написать  
gstat -r, статистика по PK-индексу: total dup >> 0, max dup =2..3 Как это может быть ?
    #38691177
Фотография Симонов Денис
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Симонов Денис
Участник
Дык это был ответ на
ТаблоидА свип что же ?
причём ранее шёл разговор о фоновом сборщике мусора, которые к sweep почти никакого отношения не имеет.
Насколько я понял из презентаций именно sweep должен быть намного быстрее за счёт флана "без мусора".
...
Рейтинг: 0 / 0
08.07.2014, 22:30
| Ответить | Цитировать | Написать  
25 сообщений из 29, страница 1 из 2
  1  все
Форумы / Firebird, InterBase [игнор отключен] [закрыт для гостей] / gstat -r, статистика по PK-индексу: total dup >> 0, max dup =2..3 Как это может быть ?
Найденые пользователи ...
Разблокировать пользователей ...
Читали тему (0):
Читали форум (0):
Пользователи онлайн (0):
Польз. соглашение   Полит. конфиден.  
NoSQL.ru       Кролег: Проекты, Новости, Чат       РЕД ФОРУМ       Фотоальбом: Участники, Встречи
Закрыть
start [/forum/topic.php?fid=40&msg=38691177&tid=1563479]:
 0ms
get settings:
 8ms
get forum list:
 18ms
check forum access:
 4ms
check topic access:
 4ms
track hit:
 175ms
get topic data:
 10ms
get forum data:
 3ms
get page messages:
 68ms
get tp. blocked users:
 1ms
others: 213ms
total:  504ms
созд. / загр.: 504ms
x
x
Закрыть


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