Подскажите можно сделать индекс не полю а например на основании udf, которая
будет обрабатывать блоб?
Можно сделать так что бы не все записи добавлялась в индекс?
Ответ на вопрос "зачем": например в таблице очень много записей и нужно
искать только небольшое количество по специфичному индексу, ес
лько и
сами данные - это плохой, негодный индекс ;-)
Индексы по выражениям строить можно и очень часто они помогают.
--
Best regards,
Sergeymailto:gebele...@gmail.com
: ru-firebird@googlegroups.com
Subject: Re: ИндексЫ
Привет!
> Подскажите можно сделать индекс не полю а например на основании udf,
которая
> будет обрабатывать блоб?
> Можно сделать так что бы не все записи добавлялась в индекс?
> Ответ на вопрос "зачем": например в таблице
сти эти 7% в отдельную таблицу и построить уже по ней правильные
индексы никак?
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, которая
будет обрабатывать блоб?
Да.
Можно сделать так что бы не все записи добавлялась в индекс?
Нет.
--
Хорсун Влад
Бу всем.
В процессе визуального контроля
результатов выполнения патча глаз
зацепился за два системных уникальных
индекса, висящих на одном и том же
наборе колонок - (ID,CLASS)
Один индекс породил первичный ключ.
Второй - FK
Глаз зацепился, а в башке стукнуло -
почему бы серверу эти два индекса н
FB 1.5.3 CS
Не далее как в прошлую субботу сделал бэкап-рестор базы, и вот сегодня
опять битые индексы :-(((
В логе вроде ничего интересного, разве что вот это:
NSH Mon Jun 26 09:21:29 2006
page 869734, page type 5 lock conversion denied (215)
но это было только один раз, иногда
Доброго дня
подскажите ответ на возможно глупый вопрос?
Если я создал ХП, потом индекс, без перекомпиляции ХП она этот индекс подхватит?
Заранее спасибо.
--
Don`t drink and drive, smoke and fly!
Kovalenko Dmitry 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
> и вот сегодня ночью при валидации обнаружилось:
> NSH Fri Jun 30 02:09:22 2006
> Index 2 is corr
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.
--~--~-~--~~~---~--~~
-~--~~~~--~~--~--~---
"Ded" <[EMAIL PROTECTED]> сообщил/сообщила в
новостях следующее: news:[EMAIL PROTECTED]
> Alexandr Kochmin wrote:
>
> > если из-за того индексы падают, то что-то тут не то с классиком.
>
>А супера если десяток раз подряд завалить - всё будет чики-чики? ;)
Та
Dmitry Voroshin wrote:
>>>если из-за того индексы падают, то что-то тут не то с классиком.
>>
>> А супера если десяток раз подряд завалить - всё будет чики-чики? ;)
>
>
> Так в том то и беда, что должно быть, а нету...
Доктор, когда я делаю вот так, мне
D> Dmitry Voroshin wrote: >>>если из-за того индексы падают, то что-то тут не
то с
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
Взаправду? :
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
--~--~-~--~~~---~--~~
-~--~~~~
"Ded" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED]
> Dmitri Kuzmenko wrote:
>Вообще-то, по идее, ничего кроме орфанов при этом получаться не
> должно, во всяком случае при FW On. Так что таки баг и таки потихоньку
FW и процесс прибиения процесса классика/серевера с разрушением
D> Alexandr Kochmin wrote: > D>Доктор, когда я делаю вот так, мне
почему-то
D> больно ;) У меня уже
D>>> года три на боевом процессы не киляются никогда. И ничо, жив пока.
D>>
D>> а как тогда всех отключать от сервера?
D> А зачем?
так чтоб базу обновить. FK например, да и вообщ
D> Alexandr Kochmin wrote: > D> Alexandr Kochmin wrote: > если из-за того
индексы
D> падают, то что-то тут не то с
D>>> классиком.
D>>>А супера если десяток раз подряд завалить - всё будет чики-чики?
D>>> ;)
D>>
D>> у супера норм
Ded wrote:
>>От чего это может, блин, быть?
> От киляния процессов. Перед ночным майнтенансом например.
Нет, такого нету. Раньше был shutdown - выключил. Полных зависаний пока
не было, а вот индексы продолжают падать.
Да, у меня 1й диалект, если это имеет значение. Перевод базы
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. Возможно у него такая же
> проблема.
А можно ссылку? Или краткое резюме?
--~--~-~--~~~---~--~~
-~--~~~~--~~--~--~---
"Konstantin R. Beliaev" <[EMAIL PROTECTED]> wrote in message news:[EMAIL
PROTECTED]
> Oleg LOA wrote:
>> Помнишь обсуждение проблем с классиком YA на SQL.RU. Возможно у него такая
>> же проблема.
> А можно ссылку? Или краткое резюме?
Резюме - ошибка в коде блокировщика
--~--~-~--~~--
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?
Нет. Но страницы пишутся по коммиту, коего не бывает
у фоновой сборки мусора. К классику, есс-но, это не относится,
посему
"Horsun Vlad" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED]
>Нет. Но страницы пишутся по коммиту, коего не бывает
> у фоновой сборки мусора. К классику, есс-но, это не относится,
> посему для него последствий меньше должно быть.
Всё равно если не падает ОС, то при чём тут FW?
--~
Oleg LOA wrote:
>> Если просто оборвался коннект, то последствий вообще не
>>должно быть. Если же его оборвали (убили процесс сервера,
>
>
> Однако практика показывает что оин могут быть ;-)
Однако, я от тебя это слышу уже лет 5, но вживую ни разу такого не
наблюдал. А у меня это не так
"Oleg LOA" ...
> "Horsun Vlad" ...
> >Нет. Но страницы пишутся по коммиту, коего не бывает
> > у фоновой сборки мусора. К классику, есс-но, это не относится,
> > посему для него последствий меньше должно быть.
>
> Всё равно если не падает ОС, то при чём тут FW?
Кеш птицы пишется в кеш ОС н
"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 транзакций в день
>
16.03.2011 17:14, Alexey Voychehovich пишет:
Если я создал ХП, потом индекс, без перекомпиляции ХП она этот индекс подхватит?
Либо перекомпиляция, либо переконнект.
--
Дмитрий Еманов
Спасибо
16.03.2011 16:30 пользователь "Dmitry Yemanov"
написал:
> 16.03.2011 17:14, Alexey Voychehovich пишет:
>>
>> Если я создал ХП, потом индекс, без перекомпиляции ХП она этот индекс
подхватит?
>
> Либо перекомпиляция, либо переконнект.
>
>
> --
> Дмитрий Еманов
>
Hello, Alexey!
Alexey Voychehovich wrote:
Доброго дня
подскажите ответ на возможно глупый вопрос?
Если я создал ХП, потом индекс, без перекомпиляции ХП она этот индекс подхватит?
если ХП уже сидит в памяти, и для нее планы созданы, то разумеется нет.
поможет реконнект.
И да, в процедуре у за
Понятно, что сильно неуникальный индекс - это плохо, вопрос: насколько?
Точнее: если у таблицы имеется индекс с селективностью, ну, скажем, 0.1,
и при апдейте меняется НЕ индексное поле, будет этот индекс оказывать
влияние на скорость апдейта или нет?
Вопрос вырос из размышлений: создавать ли
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
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
"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.
--
Хорсун Влад
Есть БД, изначально создана на 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 N
"Konstantin R. Beliaev" ...
>
> и при апдейте меняется НЕ индексное поле, будет этот индекс оказывать
> влияние на скорость апдейта или нет?
Никакой индекс не изменяется, если не изменяется его ключ.
В ОДС10 селективность индекса вообще не влияет на операцию вставки
ключа, ибо номер запи
Horsun Vlad wrote:
и при апдейте меняется НЕ индексное поле, будет этот индекс оказывать
влияние на скорость апдейта или нет?
Никакой индекс не изменяется, если не изменяется его ключ.
Я несколько запутался: при апдейте добавляется новая версия записи.
Разве индекс не меняется так чтобы
Архив БД здесь
http://hdd.shavluk.googlepages.com/TestVarcharIndex.rar
Шавлюк Евгений wrote:
Есть архив fbk (rar) 116K
Кидай мне архив на firebird2 at yandex dot ru.
--
Дмитрий Еманов
Архив БД здесь
http://hdd.shavluk.googlepages.com/TestVarcharIndex.rar
Шавлюк Евгений wrote:
Архив БД здесь
http://hdd.shavluk.googlepages.com/TestVarcharIndex.rar
Спасибо, воспроизвел.
--
Дмитрий Еманов
Пока не починили и не вышел 2.0.1 можно использовать
DESC индексы, если обстоятельства позволяют. В них этой
баги быть не должно
--
Хорсун Влад
Спасибо,
я пока отказался от этого индекса
вообще
--
Шавлюк Евгений
Я опять здесь.
Урожайный у меня день сегодня
И так 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 d
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
http://hdd.shavluk.goog
Да, наша бага в оптимизаторе. Исправил, спасибо.
--
Дмитрий Еманов
> Исправил, спасибо.
Тк... я смотрю SP1 на подходе ...
"процесс пошел", что неможет не радовать
P.S. я ж говорил... только скажите РЕЛИЗ! ...:)
P.P.S. уезжаю в отпуск... только поэтому отложил переход на FB2.
Plotnikov Y wrote:
А тема вот в чем - скажите плиз, когда (примерно, очень примерно) можно
будет рассчитывать на альфы 2.1?
До НГ.
--
Дмитрий Еманов
"Plotnikov Y" ...
>
> А, понял ;)))
> под ёлку положите ;
Под ёлкой каждый взять сможет. Мы _на_ ёлку положим :)
--
Хорсун Влад
PS Что мешает не ждать милостей от ёлки, а самому собрать ?
> Да, наша бага в оптимизаторе. Исправил, спасибо.
Блин, мы уже во все филиалы закачали
сборку 12748 :)
Коваленко Дмитрий.
Kovalenko Dmitry wrote:
Да, наша бага в оптимизаторе. Исправил, спасибо.
Блин, мы уже во все филиалы закачали
сборку 12748 :)
Эта бага мелкая, редкая и не опасная. Вот другая (в соседней ветке) -
опасная. Так что если мешаешь NULL-ы и пустые строки в одном
индексированном поле и в WHERE ра
> >> Да, наша бага в оптимизаторе. Исправил, спасибо.
> >
> > Блин, мы уже во все филиалы закачали
> > сборку 12748 :)
>
> Эта бага мелкая, редкая и не опасная. Вот другая (в соседней ветке) -
> опасная. Так что если мешаешь NULL-ы и пустые строки в одном
> индексированном поле и в WHERE разделяеш
Андрей Могильный wrote:
Дим,
а исправления таких ошибок выльются в конце концов в какое-то обновление для
FB2.0? Или просто эти исправления войдут в FB2.1? Если второе, то у многих
думаю пропадет желание переходить на FB2.0.
Ай, посчитай x в 1.0.x и в 1.5.x и успокойся. Статистика шепчет, ч
"Андрей Могильный" ...
>
> Дим,
>
> а исправления таких ошибок выльются в конце концов в какое-то обновление для
> FB2.0? Или просто эти исправления войдут в FB2.1? Если второе, то у многих
> думаю пропадет желание переходить на FB2.0.
Будет 2.0.1
Конечно намного раньше, чем 2.1
--
Хор
Андрей Могильный 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
"Gene Feudorov" ...
>
> Hello, Dmitri Kuzmenko!
> You wrote on Tue, 25 Apr 2006 16:54:15 +0400:
>
> DK> им если пользоваться, то для отчетов, чтобы "побыстрее выполнилось".
>
> а отчего для работы то нельзя!?
Если очень хочется - то можно ;) Но - не нужно.
Единственное видимое мне прим
Привет!
а скорость работы пользователей?
Влад, у нас 300 коннектов активно долбят в рабочее время!
и включение сборки мусора хорошо отображается на процессоре
а одно из основных требований заказчика - "главное, штоп не тормозило!" :-)
А что у вас за железо?
И какая конфигурация FB - буферов с
"Gene Feudorov" ...
> а скорость работы пользователей?
> Влад, у нас 300 коннектов активно долбят в рабочее время!
> и включение сборки мусора хорошо отображается на процессоре
> а одно из основных требований заказчика - "главное, штоп не тормозило!" :-)
Не верю (с) Сборка мусора - это, груб
Прямо ужасы какие-то на нось глядя :(
У нас тоже(?) сборка мусора отключена на
уровне базы данных - по ночам работает
свип. Он правда не "15 минут" работает, а
(как правило) полтора-два часа.
Разрыв в транзакциях за смену
достигает 170-200 тыс.
И мы эту базу еще и апгрейдим иногда ...
Мамаа
"Kovalenko Dmitry" ...
> Прямо ужасы какие-то на нось глядя :(
>
> У нас тоже(?) сборка мусора отключена на
> уровне базы данных - по ночам работает
> свип. Он правда не "15 минут" работает, а
> (как правило) полтора-два часа.
>
> Разрыв в транзакциях за смену
> достигает 170-200 тыс.
>
> И мы эту
>> У нас тоже(?) сборка мусора отключена на
>> уровне базы данных
>Ну хоть ты не путай сборку мусора со свипом :-)
А, ну да. Чего это я ? :)
Дим, когда целый день - с 8 до 20:00 -
продолбенишься с программированием,
начнешь путать что угодно :)
Мысль о том что это все таки разные
вещи была, но
97 matches
Mail list logo
