Re: Сверхбольшие таблицы

2006-06-21 Thread Horsun Vlad
"Dmitry Yemanov" ... > "Nikolay Ponomarenko" wrote: > > > > Продолжая, сугубо теоретические, эксперименты с большими базами, > > Кеша серверу сколько установил? > > > мучаю таблицу с 1млрд записей, джойня саму с собой > > > > select o.* from objects o > > join objects o1 on o1.p_1=o.id_obj > > wher

Re: Сверхбольшие таблицы

2006-06-21 Thread Horsun Vlad
"Nikolay Ponomarenko" ... > Hello, All! > > Продолжая, сугубо теоретические, эксперименты с большими базами, > мучаю таблицу с 1млрд записей, джойня саму с собой > > select o.* from objects o > join objects o1 on o1.p_1=o.id_obj > where o.id_obj<3 > > нидекс по p_1, есесно хуже, чем по ПК id_obj, и

Re: уЧЕТИВПМШЫЙЕ ФБВМЙГЩ

2006-06-21 Thread Nikolay Ponomarenko
Hello, Horsun! You wrote on Wed, 21 Jun 2006 10:06:48 +0300: HV> что возвращает select count(*) from objects where id_obj<3 2 -- -="Подготовьте мышь к опыту. Полученную кашицу..." (c) руководство для биологов=- With best regards, Nikolay Ponomarenko --~--~-~--~~-

Re: FB2 null

2006-06-21 Thread Serge Buzadzhy
Nikolay Ponomarenko пишет: > Hello, Serge! > You wrote on Tue, 20 Jun 2006 17:13:25 +0300: > > > ??>> Я в курсе :) Вообще-то и "or is null" достаточно нагляден. > SB> Кто нагляден? Кто "or is null"? :) > SB> Ну ка перепиши изначальный запрос > SB> select * from test_null t where (t.test_str

Re: FB2 null

2006-06-21 Thread Serge Buzadzhy
Dmitry Yemanov пишет: > "Serge Buzadzhy" <[EMAIL PROTECTED]> wrote: >> Ну ка перепиши изначальный запрос >> >> select * from test_null t where (t.test_str=:test_null0) >> >> на запрос с "or is null" так чтобы при нулл параметре он давал >> t.test_str is null... и при этом еще и работал. А я полюбу

Re: Сверхбольшие таблицы

2006-06-21 Thread Horsun Vlad
"Nikolay Ponomarenko" ... > Hello, Horsun! > You wrote on Wed, 21 Jun 2006 10:06:48 +0300: > > HV> что возвращает select count(*) from objects where id_obj<3 > > 2 Сорри, обманул я тебя : не id_obj < 3, а p_1 < 3 конечно -- Хорсун Влад --~--~-~--~~~---~--

Re: ������������ ������

2006-06-21 Thread Dmitry Yemanov
"Horsun Vlad" <[EMAIL PROTECTED]> wrote: > >> Не верю (с) По O1 нет граничных условий, так что INDEX (OBJECTS_IDX2) тут >> быть не может. Должен быть натурал. > >То самое distributing equalities ? :) > > o1.p_1=o.id_obj &&

Re: ������������ ������

2006-06-21 Thread Dmitry Yemanov
"Nikolay Ponomarenko" <[EMAIL PROTECTED]> wrote: > > А вопрос собственнов в чем - на что сервер тратит память, когда идет по > первому(неоптимальному) плану? На битмап для p_1 < 3? -- Дмитрий Ем

Re: FB2 null

2006-06-21 Thread Nikolay Ponomarenko
Hello, Serge! You wrote on Wed, 21 Jun 2006 10:27:49 +0300: ??>> select * from test_null t where (t.test_str=:test_null0) or ??>> (t.test_str is null) даст мне то, что я хочу, т.к. при нулл параметре ??>> (t.test_str=:test_null0) выпадает, разве не так? SB> Ай молодца! А при НЕ нулл параметр

Re: Небольшая проблема с Numeric

2006-06-21 Thread Oleg LOA
"ilvi" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > Добрый день. Возникла небольшая > непонятка при работе с даными Весь код приведи тогда поможем --~--~-~--~~~---~--~~ -~--~~~~--~~--~--~---

Re: Небольшая проблема с Numeric

2006-06-21 Thread Aleksey Karyakin
> хранящимися как numeric(15, 2). Диалект базы - > 3, версия сервера WI-V6.3.2.4731 Firebird 1.5. А база случайно не имела ранее диалект 1 ? > Пробелма в следующем: есть три > переменных типа numeric(15, 2), в одной > переменной хранится кол-во денег по > счету V_TPS_SUMM, во второй - суммируются

Re: Небольшая проблема с Numeric

2006-06-21 Thread Alex Cherednichenko
Привет, Aleksey! Вы пишешь 21 июня 2006: [Sorry, skipped] AK> Денежные единицы лучше хранить в банке :) В трехлитровом! (С) -- With best regards, Alex Cherednichenko. --~--~-~--~~~---~--~~ -~--~~~~--~~--~--~---

Re: Аналог CONNECT BY PRIOR

2006-06-21 Thread Oleg LOA
"Vlad Horsun" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > "Oleg LOA" ... >Ты с ораклом на вы ? Или есть ещё несчастные с этой фичей ? :) Я с ним как бы на ты, но предпочитаю всё же читать документацию ;-);-);-) --~--~-~--~~~---~--~~ -~-

Re: Аналог CONNECT BY PRIOR

2006-06-21 Thread Oleg LOA
<[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > > Oleg LOA писал(а): > >> Вот именно что ничего сложно нет и делается всё это безх всяких execute >> statment тупым написанием двух процедур для тех таблиц где есть id, parent_id > > А для любой таблички ? Если их у меня 5? > 10 проц

Re: уЧЕТИВПМШЫЙЕ ФБВМЙГЩ

2006-06-21 Thread Nikolay Ponomarenko
Hello, Horsun! You wrote on Wed, 21 Jun 2006 10:36:52 +0300: HV>>> что возвращает select count(*) from objects where id_obj<3 ??>> 2 HV> Сорри, обманул я тебя : не id_obj < 3, а p_1 < 3 конечно ага, вот оно что - там действительно, порядка половины значений таблицы, рендом работал по

Re: Сверхбольшие таблицы

2006-06-21 Thread Horsun Vlad
"Nikolay Ponomarenko" ... > HV>>> что возвращает select count(*) from objects where id_obj<3 > ??>> 2 > HV> Сорри, обманул я тебя : не id_obj < 3, а p_1 < 3 конечно > > ага, вот оно что - там действительно, порядка половины значений таблицы, > рендом работал по всему интеджеру, и в + и

Re: (unknown)

2006-06-21 Thread Karabas Barabas
Hi Dmitri Kuzmenko ! DK> Я пока на почту себе спамоборону яндекса DK> не сделал, ко мне спам валился СОТНЯМИ ПИСЕМ В ДЕНЬ! 2-й день - полет нормальный, в смысле пока что включил только пометку в теме, дак нужные письма яндекс не пометил ни разу (пока что) - --~--~---

Re: Сверхбольшие таблицы

2006-06-21 Thread Yuri Grabar
Hello, Dmitry! You wrote on Wed, 21 Jun 2006 10:22:43 +0400: DY> Такой план будет очень хорош при <3 и очень плох при >3. Оптимизатор DY> учитывает средний вариант, требующий скана половины таблицы. Дим, я тоже хотел бы спросить про оптимизатор в FB 2.0... Попытались перевести базу на него и неу

Re: Небольшая проблема с Numeric

2006-06-21 Thread Aleksey Karyakin
"ilvi" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > > В процедуре у переменной типа NUMERIC(15,2) : > RDB$FIELD_PRECISION = 15; RDB$FIELD_TYPE = 16; RDB$FIELD_SUB_TYPE = 1; Это INT64 > А в таблицах где храняться данные все > несколько иначе : RDB$FIELD_PRECISION = NULL; > RDB$

Re: ������������ ������

2006-06-21 Thread Dmitry Yemanov
"Yuri Grabar" <[EMAIL PROTECTED]> wrote: > > where DOC_DATE between ?DF and ?DT >and FROM_ID = ?FROM_ID >and DOCUMENT_ID = 2 > > FROM_ID и DOCUMENT_ID - внешние ключи, по полю DOC_DATE есть индекс. > Селективности по индексам: > > по DOC

Re: Аналог CONNECT BY PRIOR

2006-06-21 Thread Сергей Фетискин
On Wed, 21 Jun 2006 12:37:00 +0400, Oleg LOA <[EMAIL PROTECTED]> wrote: >> >>> Вот именно что ничего сложно нет и делается всё это безх всяких >>> execute statment тупым написанием двух процедур для тех таблиц где >>> есть id, parent_id >> >> А для любой таблички ? Если их у меня 5? >> 10 пр

Re: Сверхбольшие таблицы

2006-06-21 Thread Yuri Grabar
Hello, Dmitry! You wrote on Wed, 21 Jun 2006 14:22:19 +0400: DY> "Yuri Grabar" <[EMAIL PROTECTED]> wrote: > > where DOC_DATE between ?DF and DY> ?DT ??>>and FROM_ID = ?FROM_ID ??>>and DOCUMENT_ID = 2 ??>> ??>> FROM_ID и DOCUMENT_ID - внешние ключи, по полю DOC_DATE есть индекс. ??

Re: �

2006-06-21 Thread Андрій Жук
Ну, код не особо прчесан. Вот кусок. Бюджеты и статьи CREATE TABLE LINE ( MEM_IDIDENTIFIER NOT NULL /* IDENTIFIER = INTEGER NOT NULL */, MEM_NAME NAME NOT NULL /* NAME = VARCHAR(82) DEFAULT 'unknown' NOT NULL */, MEM_DESC DESCRIPTION /* DESCRIPTION = VARCHAR(255)

Re: ������������ ������

2006-06-21 Thread Dmitry Yemanov
"Yuri Grabar" <[EMAIL PROTECTED]> wrote: > > Эээ... Разве не чем меньше - тем лучше? Селективностью можно оценить кардинальность выборки только на равенство. Для больше/меньше/между эт

Re: Небольшая проблема с Numeric

2006-06-21 Thread ilvi
Целый NUMERIC - просто необходим, иначе не дружить мне с бухгалтерией. Поэтому создал пустую базу из скрипта и перенес туда данные (хорошо, что есть IBExpert). Проблема с NUMERIC исчезла, теперь даже внутри IF все нормально. Спасибо за помощь. Пойду проверять дальше таблички - может еще что вылезе

Re: Сверхбольшие таблицы

2006-06-21 Thread Horsun Vlad
"Dmitry Yemanov" ... > "Yuri Grabar" wrote: > > > > Эээ... Разве не чем меньше - тем лучше? > > Селективностью можно оценить кардинальность выборки только на равенство. Для > больше/меньше/между эта цифра не дает ничего. Поэтому сервер использует свои > коэффициенты. Для больше/меньше - 50%, для ме

Re: Сверхбольшие таблицы

2006-06-21 Thread Yuri Grabar
Hello, Dmitry! You wrote on Wed, 21 Jun 2006 14:53:03 +0400: DY> "Yuri Grabar" <[EMAIL PROTECTED]> wrote: > > Эээ... Разве не чем меньше - тем DY> лучше? DY> Селективностью можно оценить кардинальность выборки только на DY> равенство. Для больше/меньше/между эта цифра не дает ничего. Поэтому

Re: Аналог CONNECT BY PRIOR

2006-06-21 Thread Alex Cherednichenko
Привет, Сергей! Вы пишешь 21 июня 2006: СФ> *мечтательно* СФ> Вот если бы встроить функционал препроцессора в сам сервер. Чтобы можно СФ> было писать подобные запросы СФ> create table :TABLE_NAME ( СФ> ID integer, СФ> NAME varchar(32) СФ> ) СФ> Мне кажется это открыло бы широкие во

Re: (unknown)

2006-06-21 Thread Karabas Barabas
KB> 2-й день - полет нормальный, в смысле пока что включил KB> только пометку в теме, дак нужные письма яндекс не KB> пометил ни разу (пока что) отставить :( вырубил я эту спамоборону из-за вот такого ответа, полученного отправителем письма, которое я срочно ждал: The server was not able to deli

Re: Аналог CONNECT BY PRIOR

2006-06-21 Thread Ded
Alex Cherednichenko wrote: > Когда проктологи говорят о "широких возможностях", мне СТРАААШНО... А мне уже чо-то нет. Уже чо-то скушно. Ибо они только об энтом всё время и говорят... -- Regards. Ded. --~--~-~--~~~---~--~~ -~--~~~~--

Re: �

2006-06-21 Thread Андрій Жук
Забыл еще рекурсивную процедуру CREATE PROCEDURE GET_TREE_LINE ( INSET_ID INTEGER, INMEM_PID INTEGER, INLEVEL INTEGER) RETURNS ( MEM_PID INTEGER, MEM_ID INTEGER, OUTLEVEL INTEGER, IS_LEAF INTEGER, MEM_ORDER INTEGER) AS DECLARE VARIABLE CHILDID INTEGER; begin

Re: ������������ ������

2006-06-21 Thread Dmitry Yemanov
"Horsun Vlad" <[EMAIL PROTECTED]> wrote: > > Отсюда - индекс по FROM_ID лучше, чем по DOCUMENT_ID. Согласен. Но он и используется всегда. А речь про DOCUMENT_ID vs DOC_DATE. -- Дмитрий Еманов --~--~-~--~~

Re: ������������ ������

2006-06-21 Thread Dmitry Yemanov
"Yuri Grabar" <[EMAIL PROTECTED]> wrote: > > Дим, я что-то не понимаю при чем тут "на глазок". По селективности индекс > по > DOC_DATE почти в 100 раз выгоднее, чем по DOCUMENT_ID при прочих равных Ещ

Re: ������������ ������

2006-06-21 Thread Dmitri Kuzmenko
Hello, Dmitry! Dmitry Yemanov wrote: >>по DOC_DATE - 0,00048169 >>по FROM_ID - 0,00017614 >>по DOCUMENT_ID - 0,0333 > > С точки зрения стоимости, выигрывает DOCUMENT_ID. не понял. у него же селективность ХУЖЕ на 2 порÑ

Re: ������������ ������

2006-06-21 Thread Dmitri Kuzmenko
Hello, Yuri! Yuri Grabar wrote: > Дим, я что-то не понимаю при чем тут "на глазок". По селективности индекс по > DOC_DATE почти в 100 раз выгоднее, чем по DOCUMENT_ID при прочих равных > (гистогÑ

Re: (unknown)

2006-06-21 Thread Dmitri Kuzmenko
Karabas Barabas wrote: > вырубил я эту спамоборону из-за вот такого ответа, полученного отправителем > письма, которое я срочно ждал: пропускай почту через mail.ru. там тоже можно использовать ящик как "фильтр". -- Dmitri Kuzmenko, www.ibase.ru, (495) 953-13-34 --~--~-~--~~-

[no subject]

2006-06-21 Thread ru-firebird
Date:Tue, 19 Jan 2038 11:14:07 +0800 X-Mailer: Microsoft Outlook, Build 10.0.2616 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--4380729546093911381" X-Priority: 3 X-MSMail-Priority: Normal X-EM-Registration: #0130500110586300 4380729546093911381 Content-Type:

Re: (unknown)

2006-06-21 Thread Dmitri Kuzmenko
Hello, All! Unknown wrote: я могу только с грустью сообщить, что на все данные письма сделал abuse в гугл. p.s. а рекламируют, похоже, или центр китайского китайского, или что-то вроде. -- Dmitri Kuzmenko, www.ibase.ru, (495) 953-13-34 --~--~-~--~~~---~--~~ -~

Re[2]: Аналог CONNECT BY PRIOR

2006-06-21 Thread Max Rezanov
Hello Ded, Wednesday, June 21, 2006, 4:16:20 PM, you wrote: D> Alex Cherednichenko wrote: >> Когда проктологи говорят о "широких возможностях", мне СТРАААШНО... D> А мне уже чо-то нет. Уже чо-то скушно. Ибо они только об энтом всё D> время и говорят... Это значит что остальной функционал

Re: (unknown)

2006-06-21 Thread Aleksey Karyakin
"Dmitri Kuzmenko" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > p.s. а рекламируют, похоже, или центр китайского > китайского, или что-то вроде. Магазин с DVD за 50 юаней. 170 руб? Regards, Aleksey Karyakin --~--~-~--~~~---~--~~ -~--~---

Re: Сверхбольшие таблицы

2006-06-21 Thread RUST
> DY> Даже так: > > DY> where DOC_DATE between ?DF and ?DT > DY> and FROM_ID = ?FROM_ID > DY> and DOCUMENT_ID+0 = 2 > > DY> ? ... а если еще order by DOC_DATE сделать? --~--~-~--~~~---~--~~ -~--~~~~--~~--~--~---

Re: (unknown)

2006-06-21 Thread Karabas Barabas
Hi Dmitri Kuzmenko ! DK> пропускай почту через mail.ru. там тоже можно DK> использовать ящик как "фильтр". дак раньше я так и делал, вот же я написал: http://permalink.gmane.org/gmane.comp.db.firebird.russian/6869 разве что они тоже ввели такой сервис у себя ... да ну их, честно говоря, ненад

Re: Сверхбольшие таблицы

2006-06-21 Thread Константин
Hello, All! Гм, а не изменилась ли ситуация с FB2 относительно http://ibase.ru/devinfo/tablesize.htm В частности интересует: 1. >Органичение на количество записей в первую очередь вызвано наличием 4-байтового идентификатора 2. >Во всех нынешних версиях InterBase, Firebi

Re: ������������ ������

2006-06-21 Thread Dmitry Yemanov
"Константин" <[EMAIL PROTECTED]> wrote: > > Гм, а не изменилась ли ситуация с FB2 > относительно http://ibase.ru/devinfo/tablesize.htm > В частности интересует: > 1. Ограничение на количество записей Ð

Читал, читал - и нифига не понял :(

2006-06-21 Thread Константин
Hi, многоуважаемый All! http://www.ibase.ru/devinfo/oop_rdbms.htm п. Хранение более сложных объектов. п.п Вариант 2. Не совсем понятно как хранится деталировка того же заказа ... может кто обьяснит на "пальцах" ? :( Для "шапки" документа всё понятно но как организовать 1:N связки "обь

Re[2]: Сверхбольшие таблицы

2006-06-21 Thread Константин
>> 1. Ограничение на количество записей в первую очередь вызвано >> наличием 4-байтового идентификатора >Частично изменилось. Насколько частично ? Где написано не подскажешь ? >> 2. о всех нынешних версиях InterBase, Firebird и Yaffil ограничение >> на максимальный размер данных в одной табли

Re: Re[2]: ������������ ������

2006-06-21 Thread Dmitry Yemanov
"Константин" <[EMAIL PROTECTED]> wrote: > > Насколько частично ? Где написано не подскажешь ? Не подскажу. Т.к. внутренняя кухня. > Насколько сильно ? Где написано не подскажешь ? Ð

Re: ������������ ������

2006-06-21 Thread Dmitri Kuzmenko
Hello, Константин! Константин wrote: > Гм, а не изменилась ли ситуация с FB2 > относительно http://ibase.ru/devinfo/tablesize.htm > В частности интересует: на каждом углу пишут,

Re[4]: Сверхбольшие таблицы

2006-06-21 Thread Константин
>> Насколько частично ? Где написано не подскажешь ? >Не подскажу. Т.к. внутренняя кухня. Ну и ... ладно ;) >> Насколько сильно ? Где написано не подскажешь ? >Факт описан в релизных нотах. Про "насколько" - на три порядка, если я все >правильно путаю. Ok! Пошёл в очередной раз перечитыва

[no subject]

2006-06-21 Thread ru-firebird
Date:Tue, 19 Jan 2038 11:14:07 +0800 X-Mailer: The Bat! (v1.52f) Business MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--6773757807956461" X-Priority: 3 X-MSMail-Priority: Normal X-EM-Registration: #0130500110586300 X-Antivirus: avast! (VPS 0625-5, 21/06/2006), Outb

Re: ������������ ������

2006-06-21 Thread Dmitri Kuzmenko
Hello, Константин! Константин wrote: > Насколько частично ? Где написано не подскажешь ? все в релизнотах. Хотя еще раз спрошу - чем тебе НЕ нравится ограничение на 2 милÐ

Re[2]: Сверхбольшие таблицы

2006-06-21 Thread Константин
> на каждом углу пишут, что в FB 2 изменилась. У меня "фигвам" - углов нет ;) >> 1. >Органичение на количество записей в первую очередь вызвано наличием >> 4-байтового идентификатора >мало 2 миллиардов записей? А фиг его знает, может и не хватит если ООП БД строить ... Там таблиц

Re[2]: Сверхбольшие таблицы

2006-06-21 Thread Константин
>> Насколько частично ? Где написано не подскажешь ? >все в релизнотах. Хотя еще раз спрошу - чем >тебе НЕ нравится ограничение на 2 миллиарда записей в таблице? Всё нравится, но "хотса" точно знать ! Вопрос стоит именно в разрезе ООП БД пока я просто не в состоянии просчитать сколько,

Re: ������������ ������

2006-06-21 Thread Dmitri Kuzmenko
Hello, Konstantin! Константин wrote: > 2^64 ;) > или 0..18446744073709551616 > или -9223372036854775807..+9223372036854775808 я просил НАЗВАТЬ это число 807 775 тысяч 854 миллиона 036 миллиардов, 372 ... 223 ... 9 ... ? p.s. л

Re:

2006-06-21 Thread Dmitry Yemanov
"Dmitri Kuzmenko" <[EMAIL PROTECTED]> wrote: > > p.s. лично я чего там 9 уже не помню. А! Вспомнил! :-) Квинтиллионов вроде :-) -- Дмитрий Еманов --~--~-~--~~~---~--~~ -~--~~~~--~~--~--~---

Re[2]: Сверхбольшие таблицы

2006-06-21 Thread Константин
>> 2^64 ;) >> или 0..18446744073709551616 >> или -9223372036854775807..+9223372036854775808 >я просил НАЗВАТЬ это число >807 >775 тысяч >854 миллиона >036 миллиардов, >372 ... >223 ... >9 ... ? >p.s. лично я чего там 9 уже не помню. А! Вспомнил! Блин, ну ты и вопросики задаёшь :)

Re[2]: Сверхбольшие таблицы

2006-06-21 Thread Константин
Во, покурив google, нашёл http://arbuz.uz/gazeta_29.html PS: а вообще-то офигенный вопрос! не сразу и сообразишь :) Возьму на заметку PPS: За первым ответом пришлось в срочном порядке домашнюю библиотеку шерстить ;) С уважением, Константин Григорьевич. === Если "н

Re: Сверхбольшие таблицы

2006-06-21 Thread Ded
Константин wrote: > А фиг его знает, может и не хватит если ООП БД строить ... > Там таблиц 1-2 и обчёлся а записи ростут чуть ли не в > геометрической прогресии :( А доедет ли эта брика до Киева? (C) Тащусь я с объектно-ориентированных всю жись :-D -- Regards. Ded. --~

Эх ...

2006-06-21 Thread Константин
>> А фиг его знает, может и не хватит если ООП БД строить ... >> Там таблиц 1-2 и обчёлся а записи ростут чуть ли не в >> геометрической прогресии :( >А доедет ли эта брика до Киева? (C) Тащусь я с >объектно-ориентированных всю жись :-D А шо делать ? Ну достали "милый мой

Re: Эх ...

2006-06-21 Thread Константин
> Блин и не поспоришь, деньги то нормальные платят, а у самого > голова кругом ... Ну был бы хоть один гл.бух. (желательно м.п.) > сели бы, выпили, поговорили ... а так ... :( Чуствую дойдёт до встраивания в Explorer, если конечно сам раньше в психушку не угожу :) С уважением, Константин Гр

[no subject]

2006-06-21 Thread ru-firebird
Date:Tue, 19 Jan 2038 11:14:07 +0800 X-Mailer: The Bat! (v1.52f) Business MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--31498412378510305680" X-Priority: 3 X-MSMail-Priority: Normal X-EM-Registration: #0130500110586300 31498412378510305680 Content-Type: text/h

Re: (unknown)

2006-06-21 Thread Karabas Barabas
Неужто научились ?!?!? :)) --~--~-~--~~~---~--~~ -~--~~~~--~~--~--~---

Re: Сверхбольшие таблицы

2006-06-21 Thread Yuri Grabar
Hello, Dmitri! You wrote on Wed, 21 Jun 2006 17:29:44 +0400: DK> Hello, Yuri! DK> Yuri Grabar wrote: > Дим, я что-то не понимаю при чем тут "на глазок". По DK> селективности индекс по ??>> DOC_DATE почти в 100 раз выгоднее, чем по DOCUMENT_ID при прочих ??>> равных (гистограмм-то нету). По

Re: Сверхбольшие таблицы

2006-06-21 Thread Yuri Grabar
Hello, Dmitry! You wrote on Wed, 21 Jun 2006 16:54:26 +0400: [сорри, пропускаем...] ??>> PS: А можно узнать, какими будут проценты для FB 1.5, FB 2.0 на ODS 10.1 ??>> и FB 2.0 на ODS 11.0? DY> На ODS10 нет никаких процентов. Тупой он. Да-а В результате такого "поумнения" оптимизатора м

Re: ������������ ������

2006-06-21 Thread Dmitry Yemanov
"Yuri Grabar" <[EMAIL PROTECTED]> wrote: > > порядков, про которые писал ДК. :((( Получается, что полям типа даты > документа, по которым чаще всего идут выборки за период, причем за > небо

Re: , - :(

2006-06-21 Thread Nikolay Ponomarenko
Hello, Константин! You wrote on Wed, 21 Jun 2006 18:00:13 +0300: К> PS: Конечно это "некрасиво", но модет кто поделится скриптиком К> "реальной" БД (метаданные) построенной подобным образом... К> "Чиста" для образовательных целей ? К> lkg#ua.fm (лимит 100 кил) если больше дам другой я

Re: Сверхбольшие таблицы

2006-06-21 Thread Dmitry Beloshistov
Hello, Dmitry! You wrote to on Thu, 22 Jun 2006 09:32:07 +0400: >> Круто, ничего не скажешь... "Поумнел" оптимизатор называется... :((( DY> Тебе оставить rule-based оптимизатор, который всегда берет все DY> доступные индексы? Как в FB1.0? Флажок в конфиге, чтоб знал, как оптимизировать...

Re: Сверхбольшие таблицы

2006-06-21 Thread Nikolay Ponomarenko
Hello, Константин! You wrote to Dmitri Kuzmenko on Wed, 21 Jun 2006 18:49:10 +0300: ??>>> 1. >Органичение на количество записей в первую очередь вызвано ??>>> наличием 4-байтового идентификатора ??>> мало 2 миллиардов записей? К> А фиг его знает, может и не хватит если ООП БД строить ...

Re: , - :(

2006-06-21 Thread Dmitry Lendel
Привет > -=Чем чаще женщина стонет ночью, тем реже она ворчит днем.=- :-))) Dmytro Lendel www.bagel.com.ua --~--~-~--~~~---~--~~ -~--~~~~--~~--~--~---

Re: Сверхбольшие таблиы

2006-06-21 Thread Karabas Barabas
Hi Dmitry Beloshistov ! DB> Флажок в конфиге, чтоб знал, как оптимизировать... Тоже для поддержания разговора: конфиг навсегда, а вот опция при коннекте . - --~--~-~--~~~---~--~~ -~--~~~~--~~--~--~---

Re: Сверхбольшие таблицы

2006-06-21 Thread Boulitchev Aleksey
"Yuri Grabar" > Да-а В результате такого "поумнения" оптимизатора мы получили > ухудшение > производительности на некоторых отчетах как раз порядка тех самых двух > порядков, про которые писал ДК. :((( Получается, что полям типа даты > документа, по которым чаще всего идут выборки за период,