индекс ;-)
Индексы по выражениям строить можно и очень часто они помогают.
--
Best regards,
Sergeymailto:gebele...@gmail.com
To: ru-firebird@googlegroups.com
Subject: Re: ИндексЫ
Привет!
Подскажите можно сделать индекс не полю а например на основании udf,
которая
будет обрабатывать блоб?
Можно сделать так что бы не все записи добавлялась в индекс?
Ответ на вопрос зачем: например в таблице очень много записей и нужно
отдельную таблицу и построить уже по ней правильные
индексы никак?
WBR, Dmitry Beloshistov AKA [-=BDS=-]
19.09.2011 14:33, Михаил Викторович пишет:
Мне нужно поострить индекс в который будут добавлены, например только 7%, от
общего количества записей. Просто остальные записи для поиска по этому
индексу не нужны. Наличие не нужных записей в индексе очень заметно тормозит
вставку новых записей в
Решение связанное с разбиением таблиц очевидное, и не интересное совсем.
Вопрос про индексы остался открытым или твердое нет?
-Original Message-
From: ru-firebird@googlegroups.com [mailto:ru-firebird@googlegroups.com] On
Behalf Of dennis redozubov
Sent: Monday, September 19, 2011 2:52 PM
Решение связанное с разбиением таблиц очевидное, и не интересное совсем.
есть два варианта:
а) разбить таблицу на две одинаковых, в одной 7%, в другой 93%
б) сделать еще одну таблицу, в которой хранится только одно поле - PK из
большой таблицы.
те самые 7% PK
В вашем случае в таблице лучше
Михаил Викторович ...
Подскажите можно сделать индекс не полю а например на основании udf, которая
будет обрабатывать блоб?
Да.
Можно сделать так что бы не все записи добавлялась в индекс?
Нет.
--
Хорсун Влад
Подскажите можно сделать индекс не полю а например на основании udf, которая
будет обрабатывать блоб?
Можно сделать так что бы не все записи добавлялась в индекс?
Ответ на вопрос зачем: например в таблице очень много записей и нужно
искать только небольшое количество по специфичному индексу,
Hello, Alexey!
Alexey Voychehovich wrote:
Доброго дня
подскажите ответ на возможно глупый вопрос?
Если я создал ХП, потом индекс, без перекомпиляции ХП она этот индекс подхватит?
если ХП уже сидит в памяти, и для нее планы созданы, то разумеется нет.
поможет реконнект.
И да, в процедуре у
Доброго дня
подскажите ответ на возможно глупый вопрос?
Если я создал ХП, потом индекс, без перекомпиляции ХП она этот индекс подхватит?
Заранее спасибо.
--
Don`t drink and drive, smoke and fly!
16.03.2011 17:14, Alexey Voychehovich пишет:
Если я создал ХП, потом индекс, без перекомпиляции ХП она этот индекс подхватит?
Либо перекомпиляция, либо переконнект.
--
Дмитрий Еманов
Спасибо
16.03.2011 16:30 пользователь Dmitry Yemanov dim...@users.sf.net
написал:
16.03.2011 17:14, Alexey Voychehovich пишет:
Если я создал ХП, потом индекс, без перекомпиляции ХП она этот индекс
подхватит?
Либо перекомпиляция, либо переконнект.
--
Дмитрий Еманов
Alexey Popov ...
Вот тут я не нашёл описания низкоуровневых подробностей.
Битовая маска строится для всей таблицы целиком?
Означает ли построение битовой маски что надо прочитать все страницы индекса?
Сканируется диапазон ключей индекса и все найденные номера записей
помещаются в
Alexey Popov ...
Vlad Khorsun wrote:
Сканируется диапазон ключей индекса и все найденные номера записей
помещаются в разреженный битмап.
Что то не понимаю как технически устроена эта карта. Битмап это массив бит. Как
туда можно поместить номера?
Эти биты сами пронумерованы :)
Alexey Popov ...
Vlad Khorsun wrote:
Эти биты сами пронумерованы :)
00010011 - битовая карта, в которой установлены биты 0, 1 и 4
Это аналог сортированного массива из целых чисел 0, 1 и 4
Да, я так и думал. Остаётся понять в каком порядке идут эти биты - согласно
индексу от
Dmitri Kuzmenko ...
where a = 5 and b = 10
при отдельных индексах по a и b
1. будет построена битовая маска по a
2. будет построена битовая маска по b
3. обе битовые маски будут слиты операцией AND
2 и 3 давно уже делаются как одно действие, потребляя меньше памяти и CPU.
--
Хорсун Влад
Nikolay Ponomarenko ...
Столкнулся со странной ситуацией, когда в свежесозданной из скрипта БД, индекс для временной таблицы не подхватывается никаким
запросом. Как только пересоздать, или создать идентичный индекс для таблицы - все становится на свои места.
Из странностей в RDB$INDICES для
Nikolay Ponomarenko ...
становится на свои места. Из странностей в RDB$INDICES для этого индекса
RDB$INDEX_ID равен 819 :-/
VK Похоже на http://tracker.firebirdsql.org/browse/CORE-1838
...
FB embed 2.1.1.17910
VK Ты уверен, что 2.1.1, а не 2.1.0 ?
Перепроверил, версия файла
Николай Пономаренко ...
Кстати, только у нас, как я, с наскоку правда, понял - несколько
_полноценных_ транзакций в одном соединении.
Очень был сим фактом огорчен.
Может кто знает, где еще такое есть(не вложенные, не автономные - а наши
родные параллельные)?
MSSQL-фанатики
Пока не починили и не вышел 2.0.1 можно использовать
DESC индексы, если обстоятельства позволяют. В них этой
баги быть не должно
--
Хорсун Влад
Спасибо,
я пока отказался от этого индекса
вообще
--
Шавлюк Евгений
Да, наша бага в оптимизаторе. Исправил, спасибо.
Блин, мы уже во все филиалы закачали
сборку 12748 :)
Коваленко Дмитрий.
Kovalenko Dmitry wrote:
Да, наша бага в оптимизаторе. Исправил, спасибо.
Блин, мы уже во все филиалы закачали
сборку 12748 :)
Эта бага мелкая, редкая и не опасная. Вот другая (в соседней ветке) -
опасная. Так что если мешаешь NULL-ы и пустые строки в одном
индексированном поле и в WHERE
Да, наша бага в оптимизаторе. Исправил, спасибо.
Блин, мы уже во все филиалы закачали
сборку 12748 :)
Эта бага мелкая, редкая и не опасная. Вот другая (в соседней ветке) -
опасная. Так что если мешаешь NULL-ы и пустые строки в одном
индексированном поле и в WHERE разделяешь их - будут
Андрей Могильный wrote:
Дим,
а исправления таких ошибок выльются в конце концов в какое-то обновление для
FB2.0? Или просто эти исправления войдут в FB2.1? Если второе, то у многих
думаю пропадет желание переходить на FB2.0.
Ай, посчитай x в 1.0.x и в 1.5.x и успокойся. Статистика шепчет,
Андрей Могильный wrote:
а исправления таких ошибок выльются в конце концов в какое-то обновление для
FB2.0? Или просто эти исправления войдут в FB2.1? Если второе, то у многих
думаю пропадет желание переходить на FB2.0.
Перед 2.0.1 постараемся еще организовать снапшоты ветки 2.0.x. Т.к. там
Андрей Могильный wrote:
Во! Это я и хотел услышать! Ладно, ребят, плывем дальше. :)
http://tracker.firebirdsql.org/browse/CORE?report=com.atlassian.jira.plugin.system.project:roadmap-panel
--
Дмитрий Еманов
Horsun Vlad пишет:
Под ёлкой каждый взять сможет. Мы _на_ ёлку положим :)
Т.е. вместо отмечания НГ будете ударными темпами готовить релиз 2.1? ;-)
--
С уважением,
Андрей Еремин.
Hello, Andrei!
You wrote on Thu, 30 Nov 2006 16:24:49 +0300:
Под ёлкой каждый взять сможет. Мы _на_ ёлку положим :)
AY Т.е. вместо отмечания НГ будете ударными темпами готовить релиз 2.1? ;-)
Ну не релиз же ж! Речь только об альфе шла!
Удач
--
Alexander A. Venikov, Tobolsk, Russia
Real
Есть БД, изначально создана на FB 1.5
Вчера попробовал перевести на 2.0.
Возникла ошибка при индексном поиске
по VARCHAR
Упростил БД до минимума
CREATE DOMAIN DID AS INTEGER NOT NULL;
CREATE DOMAIN DSTRING10N AS VARCHAR(10) DEFAULT '' COLLATE WIN1251_UA;
CREATE TABLE DOC (
ID DID NOT
Архив БД здесь
http://hdd.shavluk.googlepages.com/TestVarcharIndex.rar
Шавлюк Евгений wrote:
Есть архив fbk (rar) 116K
Кидай мне архив на firebird2 at yandex dot ru.
--
Дмитрий Еманов
Шавлюк Евгений wrote:
Архив БД здесь
http://hdd.shavluk.googlepages.com/TestVarcharIndex.rar
Спасибо, воспроизвел.
--
Дмитрий Еманов
Я опять здесь.
Урожайный у меня день сегодня
И так FB 2.0
есть запрос
select d.id, i.name
from docdet d
left join item i on i.id = d.id_item
where d.ID_DOC = :mas_id and d.i2 is null
Я пользуюсь FIB, довольно старой
версией.
Естественно, установленно Option.poNoForceIsNull
= false
т.е. запрос
Статистику индексов лучше пожи
Шавлюк Евгений wrote:
select d.id, i.name
from docdet d
left join item i on i.id = d.id_item
where d.ID_DOC is null and d.i2 is null
PLAN JOIN (D NATURAL, I INDEX (PK_ITEM))
если я меняю местами выражения в where
select d.id, i.name
from docdet d
left join item i on i.id = d.id_item
where
PK_DOCDET 0.0051852833849
FK_DOCDET 0.3330557956360
DOCDET_IDX1 0.0126692452795
ITEM_ITEM 0.00063091481570154
ITEM_IDX1 0.00065832783002406
PK_ITEM 0.00011749500845326
Пример разделил на 5 частей (вместе 4.5M)
http://hdd.shavluk.googlepages.com/LLK3_docdet.part01.rar
http://hdd.shavluk.googlepages.com/LLK3_docdet.part02.rar
http://hdd.shavluk.googlepages.com/LLK3_docdet.part03.rar
http://hdd.shavluk.googlepages.com/LLK3_docdet.part04.rar
Да, наша бага в оптимизаторе. Исправил, спасибо.
--
Дмитрий Еманов
Plotnikov Y wrote:
А тема вот в чем - скажите плиз, когда (примерно, очень примерно) можно
будет рассчитывать на альфы 2.1?
До НГ.
--
Дмитрий Еманов
Plotnikov Y ...
А, понял ;)))
под ёлку положите ;
Под ёлкой каждый взять сможет. Мы _на_ ёлку положим :)
--
Хорсун Влад
PS Что мешает не ждать милостей от ёлки, а самому собрать ?
Бу всем.
В процессе визуального контроля
результатов выполнения патча глаз
зацепился за два системных уникальных
индекса, висящих на одном и том же
наборе колонок - (ID,CLASS)
Один индекс породил первичный ключ.
Второй - FK
Глаз зацепился, а в башке стукнуло -
почему бы серверу эти два индекса
Kovalenko Dmitry wrote:
Или оно и так на самом деле сделано, и я
открыл Америку? :)
Не сделано. Но когда-нибудь будет. Возможно :-)
--
Дмитрий Еманов
Horsun Vlad [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED]
Oleg LOA ...
Кеш птицы пишется в кеш ОС намного дольше, при включенном FW.
Вот и не успевает, при падении процесса. Пишется он или после окончания
сборки мусора (сразу много страниц), или при нехватке страниц в кеше
Ded [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED]
Однако, я от тебя это слышу уже лет 5, но вживую ни разу такого не
наблюдал. А у меня это не так чтоб рутинная практика, но нередко. В
приложениях если возникает непредусмотренный нами exception, то
Пишешь простую тест систму
Oleg LOA ...
Horsun Vlad ...
Oleg LOA ...
Кеш птицы пишется в кеш ОС намного дольше, при включенном FW.
Вот и не успевает, при падении процесса. Пишется он или после окончания
сборки мусора (сразу много страниц), или при нехватке страниц в кеше
(постепенно, по мере их вытеснения).
Oleg LOA wrote:
Пишешь простую тест систму - типа TPCR,запускаешь процессов 200 которые
интенисвно насилуют базу обновлениями/удалениями. Отрубаешь нахрен сетевые
интерфейсы - и
так до несколько раз. Далее тестируешь БД.
Вот-вот, TPC система, клиентов под сотню, 6 транзакций в день
Oleg LOA wrote:
Резюме - ошибка в коде блокировщика
Дурацкий вопрос: а при сборке мусора индексы обновляются? Например, при
чистке версий удаленных записей.
Корректно ли обработается ситуация если в процессе этой самой сборки
оборвался коннект?
--~--~-~--~~~---~--~~
-~--~~~~--~~--~--~---
Konstantin R. Beliaev ...
Oleg LOA wrote:
Резюме - ошибка в коде блокировщика
Дурацкий вопрос: а при сборке мусора индексы обновляются? Например, при
чистке версий удаленных записей.
Да
Корректно ли обработается ситуация если в процессе этой самой сборки
оборвался коннект
Horsun Vlad wrote:
Максимум что будет - лишние записи в индексе и\или orphan pages.
По идее :)
А на практике? ;-)
Насколько понимаю, именно это и будет рассматриваться GFIX-ом как index
corrupt, так? Как раз про orphan pages в индексе он что-то и говорил.
Konstantin R. Beliaev ...
Horsun Vlad wrote:
Максимум что будет - лишние записи в индексе и\или orphan pages.
По идее :)
А на практике? ;-)
С FW=ON так и должно быть. Практика у тебя у самого есть :)
Я такое не практикую
Насколько понимаю, именно это и будет рассматриваться
Horsun Vlad [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED]
С FW=ON так и должно быть. Практика у тебя у самого есть :)
Я такое не практикую
А при чём тут FW=ON?
Корректно ли обработается ситуация если в процессе этой самой сборки
оборвался коннект?
--
Если просто
Oleg LOA ...
Horsun Vlad ...
С FW=ON так и должно быть. Практика у тебя у самого есть :)
Я такое не практикую
А при чём тут FW=ON?
Много страниц в кеше болтается
Корректно ли обработается ситуация если в процессе этой самой сборки
оборвался коннект?
--
Если просто
Horsun Vlad [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED]
Много страниц в кеше болтается
В каком кэше? Вы там в двойке время сбрасыаиня кэша FB (не кэша ОС) сделали
зависимым от FW?
--~--~-~--~~~---~--~~
Oleg LOA ...
Horsun Vlad ...
Много страниц в кеше болтается
В каком кэше? Вы там в двойке время сбрасыаиня кэша FB (не кэша ОС) сделали
зависимым от FW?
Нет. Но страницы пишутся по коммиту, коего не бывает
у фоновой сборки мусора. К классику, есс-но, это не относится,
посему для него
Oleg LOA wrote:
Если просто оборвался коннект, то последствий вообще не
должно быть. Если же его оборвали (убили процесс сервера,
Однако практика показывает что оин могут быть ;-)
Однако, я от тебя это слышу уже лет 5, но вживую ни разу такого не
наблюдал. А у меня это не так чтоб
Ded wrote:
От чего это может, блин, быть?
От киляния процессов. Перед ночным майнтенансом например.
Нет, такого нету. Раньше был shutdown - выключил. Полных зависаний пока
не было, а вот индексы продолжают падать.
Да, у меня 1й диалект, если это имеет значение. Перевод базы на 3й не
Ded wrote:
А зачем? Чтоб под ногами не путались достаточно шатдауна
У меня есть подозрение, что шатдаун длинного запроса небезопасен. Не
уверен, что из-за этого, но несколько раз у меня на классике зависал
блокировщик, и ситуация была именно такая: длинный запрос + шатдаун.
Dmitry Voroshin wrote:
Для мата талант нужен... Эх...
Ded-у надо выпустить цитатник ;))
Что-то типа Как отключить всех юзеров от базы за 5 минут без помощи рук
--~--~-~--~~~---~--~~
-~--~~~~--~~--~--~---
Konstantin R. Beliaev wrote:
От киляния процессов. Перед ночным майнтенансом например.
Нет, такого нету. Раньше был shutdown - выключил. Полных зависаний пока
не было, а вот индексы продолжают падать.
Тряси железо. Начинай с RAM.
--
Regards. Ded.
--~--~-~--~~~---~--~~
-~--~~~~--~~--~--~---
Ded [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED]
Konstantin R. Beliaev wrote:
От киляния процессов. Перед ночным майнтенансом например.
Нет, такого нету. Раньше был shutdown - выключил. Полных зависаний пока
не было, а вот индексы продолжают падать.
Тряси железо
Oleg LOA wrote:
Помнишь обсуждение проблем с классиком YA на SQL.RU. Возможно у него такая же
проблема.
А можно ссылку? Или краткое резюме?
--~--~-~--~~~---~--~~
-~--~~~~--~~--~--~---
Sn: Yetkili, İş Ortaklığı Davetimizdir.
Konu: Mısır Kurutma-Çeltik Kurutma
ÇELTİK KURUTMA
Uzun yıllardır üretmekte olduğumuz proje ve patenti firmamıza ait olan Çeltik
Kurutma Makinalarını, yurt içinde siz değerli iş ortaklarımıza satışa
sunulmuştur. Ülkemizdeki satış organizasyonumuza
Konstantin R. Beliaev [EMAIL PROTECTED] wrote in message news:[EMAIL
PROTECTED]
Oleg LOA wrote:
Помнишь обсуждение проблем с классиком YA на SQL.RU. Возможно у него такая
же проблема.
А можно ссылку? Или краткое резюме?
Резюме - ошибка в коде блокировщика
Sn: Yetkili, İş Ortaklığı Davetimizdir.
Konu: Mısır Kurutma-Çeltik Kurutma
ÇELTİK KURUTMA
Uzun yıllardır üretmekte olduğumuz proje ve patenti firmamıza ait olan Çeltik
Kurutma Makinalarını, yurt içinde siz değerli iş ortaklarımıza satışa
sunulmuştur. Ülkemizdeki satış organizasyonumuza
FB 1.5.3 CS
Не далее как в прошлую субботу сделал бэкап-рестор базы, и вот сегодня
опять битые индексы :-(((
В логе вроде ничего интересного, разве что вот это:
NSH Mon Jun 26 09:21:29 2006
page 869734, page type 5 lock conversion denied (215)
но это было только один раз, иногда
но это было только один раз, иногда возникают
NSH Mon Jun 26 09:38:19 2006
INET/inet_error: read errno = 10054
NSH Tue Jun 27 10:22:53 2006
SERVER/process_packet: broken port, server exiting
и вот сегодня ночью при валидации обнаружилось:
NSH Fri Jun 30 02:09:22 2006
Index 2 is corrupt on
Oleg LOA wrote:
Как вариант отвалившийся процесс классика при работе с индексом.
если они сыплются из-за этого:
NSH Mon Jun 26 09:38:19 2006
INET/inet_error: read errno = 10054
NSH Tue Jun 27 10:22:53 2006
SERVER/process_packet: broken port, server exiting
то это по крайней мере странно:
Konstantin R. Beliaev wrote:
От чего это может, блин, быть?
От киляния процессов. Перед ночным майнтенансом например.
--
Regards. Ded.
--~--~-~--~~~---~--~~
-~--~~~~--~~--~--~---
D Konstantin R. Beliaev wrote: От чего это может, блин, быть?
D От киляния процессов. Перед ночным майнтенансом например.
если из-за того индексы падают, то что-то тут не то с классиком.
Чтобы не говорили, но килять то приходится. Это можно считать штатной
ситуацией, хоть и безвыходной
Alexandr Kochmin wrote:
если из-за того индексы падают, то что-то тут не то с классиком.
А супера если десяток раз подряд завалить - всё будет чики-чики? ;)
--
Regards. Ded.
--~--~-~--~~~---~--~~
-~--~~~~--~~--~--~---
Dmitry Voroshin wrote:
если из-за того индексы падают, то что-то тут не то с классиком.
А супера если десяток раз подряд завалить - всё будет чики-чики? ;)
Так в том то и беда, что должно быть, а нету...
Доктор, когда я делаю вот так, мне почему-то больно ;) У меня уже
года три на
D Dmitry Voroshin wrote: если из-за того индексы падают, то что-то тут не
то с
D классиком.
D
DА супера если десяток раз подряд завалить - всё будет чики-чики?
D ;)
D
D Так в том то и беда, что должно быть, а нету...
DДоктор, когда я делаю вот так, мне почему-то больно ;) У
D Alexandr Kochmin wrote: если из-за того индексы падают, то что-то тут не
то с
D классиком.
DА супера если десяток раз подряд завалить - всё будет чики-чики? ;)
у супера нормально работает shutdown
--
С уважением
Кочмин Александр
--~--~-~--~~~---~--~~
-~--~~~~--~~--~--~---
Ded [EMAIL PROTECTED] сообщил/сообщила в
новостях следующее: news:[EMAIL PROTECTED]
Dmitry Voroshin wrote:
если из-за того индексы падают, то что-то тут не то с классиком.
А супера если десяток раз подряд завалить - всё будет чики-чики? ;)
Так в том то и беда, что должно быть, а
Alexandr Kochmin wrote:
DДоктор, когда я делаю вот так, мне почему-то больно ;) У меня уже
D года три на боевом процессы не киляются никогда. И ничо, жив пока.
а как тогда всех отключать от сервера?
А зачем? Чтоб под ногами не путались достаточно шатдауна и фиг с ним
что
Ded [EMAIL PROTECTED] сообщил/сообщила в
новостях следующее: news:[EMAIL PROTECTED]
Alexandr Kochmin wrote:
DДоктор, когда я делаю вот так, мне почему-то больно ;) У меня уже
D года три на боевом процессы не киляются никогда. И ничо, жив пока.
а как тогда всех отключать от
Yurij wrote:
а как тогда всех отключать от сервера?
tcpview соединение прикрыть, сервер сам и закроется.
Не буду спорить про винду и супер, но пИнгвин-классике выгрузка
xinetd пофиг. Не работают, но висят, как и при шатдауне.
--
Regards. Ded.
Alexandr Kochmin wrote:
D Alexandr Kochmin wrote: если из-за того индексы падают, то что-то тут
не то с
D классиком.
DА супера если десяток раз подряд завалить - всё будет чики-чики? ;)
у супера нормально работает shutdown
Взаправду? :-D Двойку я ещё не тряс правда
Dmitri Kuzmenko wrote:
Ну знаешь. Всё таки это баг и должен потихоньку правиться. Порча БД сервером
всё таки одна из самых опасных проблем. Причём неважно при каких
обстоятельствах это происходит (я не беру в учёт кривое железо - тут уж
ничего не поделаешь).
что значит неважно? Ресет сервера
Ded [EMAIL PROTECTED] сообщил/сообщила в
новостях следующее: news:[EMAIL PROTECTED]
Alexandr Kochmin wrote:
D Alexandr Kochmin wrote: если из-за того индексы падают, то что-то
тут не то с
D классиком.
DА супера если десяток раз подряд завалить - всё будет чики-чики?
;)
у
On Fri, 30 Jun 2006 14:25:50 +0400, Dmitry Voroshin
[EMAIL PROTECTED] wrote:
Для мата талант нужен... Эх...
Говорят в армии готовят отличных специалистов :)
--
Фетискин Сергей
http://stella-npf.ru
--~--~-~--~~~---~--~~
D Alexandr Kochmin wrote: D Alexandr Kochmin wrote: если из-за того
индексы
D падают, то что-то тут не то с
D классиком.
DА супера если десяток раз подряд завалить - всё будет чики-чики?
D ;)
D
D у супера нормально работает shutdown
D Взаправду? :-D Двойку я ещё не тряс
Прямо ужасы какие-то на нось глядя :(
У нас тоже(?) сборка мусора отключена на
уровне базы данных - по ночам работает
свип. Он правда не 15 минут работает, а
(как правило) полтора-два часа.
Разрыв в транзакциях за смену
достигает 170-200 тыс.
И мы эту базу еще и апгрейдим иногда ...
Kovalenko Dmitry ...
Прямо ужасы какие-то на нось глядя :(
У нас тоже(?) сборка мусора отключена на
уровне базы данных - по ночам работает
свип. Он правда не 15 минут работает, а
(как правило) полтора-два часа.
Разрыв в транзакциях за смену
достигает 170-200 тыс.
И мы эту базу еще и
У нас тоже(?) сборка мусора отключена на
уровне базы данных
Ну хоть ты не путай сборку мусора со свипом :-)
А, ну да. Чего это я ? :)
Дим, когда целый день - с 8 до 20:00 -
продолбенишься с программированием,
начнешь путать что угодно :)
Мысль о том что это все таки разные
вещи была, но
Gene Feudorov ...
Hello, Dmitri Kuzmenko!
You wrote on Tue, 25 Apr 2006 16:54:15 +0400:
DK им если пользоваться, то для отчетов, чтобы побыстрее выполнилось.
а отчего для работы то нельзя!?
Если очень хочется - то можно ;) Но - не нужно.
Единственное видимое мне применение -
Привет!
а скорость работы пользователей?
Влад, у нас 300 коннектов активно долбят в рабочее время!
и включение сборки мусора хорошо отображается на процессоре
а одно из основных требований заказчика - главное, штоп не тормозило! :-)
А что у вас за железо?
И какая конфигурация FB - буферов
Gene Feudorov ...
а скорость работы пользователей?
Влад, у нас 300 коннектов активно долбят в рабочее время!
и включение сборки мусора хорошо отображается на процессоре
а одно из основных требований заказчика - главное, штоп не тормозило! :-)
Не верю (с) Сборка мусора - это, грубо
Понятно, что сильно неуникальный индекс - это плохо, вопрос: насколько?
Точнее: если у таблицы имеется индекс с селективностью, ну, скажем, 0.1,
и при апдейте меняется НЕ индексное поле, будет этот индекс оказывать
влияние на скорость апдейта или нет?
Вопрос вырос из размышлений: создавать
Horsun Vlad wrote:
и при апдейте меняется НЕ индексное поле, будет этот индекс оказывать
влияние на скорость апдейта или нет?
Никакой индекс не изменяется, если не изменяется его ключ.
Я несколько запутался: при апдейте добавляется новая версия записи.
Разве индекс не меняется так
91 matches
Mail list logo
