Вычисление селективности индекса для BETWEEN, LESS, GREAT и STARTING
Hello, All! Возвращаясь к пройденной теме... Итак, файл Optimize.cpp со строки 1584: // Adjust the compound selectivity using the reduce factor. // It should be better than the previous segment but worse // than a full match. const double diffSelectivity = scratch[i]-selectivity - selectivity; selectivity += (diffSelectivity * factor); fb_assert(selectivity = scratch[i]-selectivity); scratch[i]-selectivity = selectivity; scratch[i]-selectivity - начальная селективность для оценки (равна MAX_SELECTIVITY, т.е. 1.0) selectivity- селективность текущего индекса factor- фактор уменьшения влияния селективности для between = 0.2 Вычисление результирующей селективности происходит немного станно... При изменении исходной селективности индекса от 0 до 1 вычисленная результирующая селективность изменяется от 0.2 до 1.0. Не должна ли результирующая селективность вычисляться хотя бы: scratch[i]-selectivity = selectivity + selectivity * factor; ? Так, как она вычисляется сейчас получается, что любой индекс фактически не будет использоваться... Нет ли здесь ошибки? Именно так и задумывалось? -- With best regards, Yuri Grabar. --~--~-~--~~~---~--~~ -~--~~~~--~~--~--~---
Re: ������������ �����
Hello, Alexander! Alexander Goldun wrote: A good plan, not necessarily the best plan Да ладно, с этим все ясно. План хороший, плохой, злой... :-) Ты лучше скажи, как там у вас с пересчетом селективности индексов - когда она делается? -- Dmitri Kuzmenko, www.ibase.ru, (495) 953-13-34 --~--~-~--~~~---~--~~ -~--~~~~--~~--~--~---
Re: ÷ÙÞÉÓÌÅÎÉÅ ÓÅÌÅËÔÉ×ÎÏÓÔÉ ÉÎÄÅËÓÁ ÄÌÑ BETWEEN, LESS, GREAT É STARTING
Hello, Yuri! You wrote to All on Tue, 27 Jun 2006 09:24:54 +0300: YG ? Так, как она вычисляется сейчас получается, что любой индекс YG фактически не будет использоваться... Нет ли здесь ошибки? Именно YG так и задумывалось? Вроде Влад всё объяснил. Если мы имеем запрос с или (=, =), В СРЕДНЕМ, независимо от наличия/отсутствия индекса мы выбираем половину таблицы. Отсюда - 0.5. BETWEEN - комбинация из = и =. То есть, опять же, В СРЕДНЕМ, between выбирает четверть таблицы. Естественно, зависит от... (от реальных значений параметров). Но на этапе prepare значения параметров неизвестны, оптимизатор об этих значениях ничего не знает. Отсюда и числа - 0.5 и 0.2 (немножко меньше, чем 0.25). Удач -- Alexander A. Venikov, Tobolsk, Russia Real e-mail address is venixangry_dogtndottobdotru --~--~-~--~~~---~--~~ -~--~~~~--~~--~--~---
Re: Сверхбольшие таблиы
Dmitri Kuzmenko пишет: Ты лучше скажи, как там у вас с пересчетом селективности индексов - когда она делается? А зачем нужна селективность индексов если есть гистограммы распределения значений в полях? Статистика собирается и апдейтится обычно автоматически, но при необходимости есть возможность дропнуть ее: http://www.ianywhere.com/developer/product_manuals/sqlanywhere/0902/en/html/dbrfen9/0405.htm или пересоздать: http://www.ianywhere.com/developer/product_manuals/sqlanywhere/0902/en/html/dbrfen9/0374.htm А вот и банальности в общих словах про Optimizer estimates and histograms: http://www.ianywhere.com/developer/product_manuals/sqlanywhere/0902/en/html/dbugen9/0392.htm Цитата оттуда: Adaptive Server Anywhere updates histograms as a by-product of query execution. As queries are executed, Adaptive Server Anywhere compares the number of rows estimated by the histograms for a given predicate with the number of rows actually found to satisfy the predicate, and then adjusts the values in the histogram to reduce the margin of error for subsequent optimizations. Этот процесс можно наблюдать, если интересно. Например дропнуть статистику, начать выполнять запросы с разными условиями и смотреть при этом как заполняется и уточняется статистика: http://www.ianywhere.com/developer/product_manuals/sqlanywhere/0902/en/html/dbrfen9/0640.htm --~--~-~--~~~---~--~~ -~--~~~~--~~--~--~---
Re: ���������� ������������� ������� ��� BETWEEN, LESS, GREAT � STARTING
Yuri Grabar [EMAIL PROTECTED] wrote: Вычисление результирующей селективности происходит немного станно... Это алгоритм для композитов. Но похоже, что он же работает и для односегментных индексов, а это не задумывалось. Проверяю сейчас. -- Дмитрий Еманов --~--~-~--~~~---~--~~ -~--~~~~--~~--~--~---
Re: Сверхбольшие таблиы
Horsun Vlad пишет: Ты лучше скажи, как там у вас с пересчетом селективности индексов - когда она делается? А зачем нужна селективность индексов если есть гистограммы распределения значений в полях? Индексы бывают из более чем одного поля. Понял. Увы, не вникал. Не владею вопросом. Этот процесс можно наблюдать, если интересно. Например дропнуть статистику, начать выполнять запросы с разными условиями и смотреть при этом как заполняется и уточняется статистика: http://www.ianywhere.com/developer/product_manuals/sqlanywhere/0902/en/html/dbrfen9/0640.htm А сравнивать её с настоящей потом никто не пробовал ? Не понял вопроса. А в чем сомнения? Сейчас попробовал дропнуть статистику в одной табличке с 4 млн записей. Повыполнял в системе несколько запросов с разными условиями. Первые выполнения, естественно, заметно тормозили. Взял из гистограммы первое попавшееся значение и сравнил с фактическим распределением. Совпадает. А должно было не совпадать? Поехать она может при определенных условиях, как я понимаю. Но первый же запрос, который наткнется на несоответствие, уточнит ее. --~--~-~--~~~---~--~~ -~--~~~~--~~--~--~---
Re: Сверхбольшие таблиы
Не понял вопроса. А в чем сомнения? Сейчас попробовал дропнуть
Пожалуй, дропанье статистики дало не очень показательный пример. Вот
имел честь наблюдать как расхождение, так и исправление. Вызвал по
другой базе следующее
call sa_get_histogram ('store_id','store_movement')
Получил для store_id=7 величину 0.0028850038
А результат такого запроса:
SELECT cast((select count(*) from store_movement where store_id=7)as
double)/ (select count(*) from store_movement)
вернул 0.0030593773
И этот же запрос подкорректировал величину - второй вызов
sa_get_histogram показал уже исправленное значение 0.0030593773
--~--~-~--~~~---~--~~
-~--~~~~--~~--~--~---
Re: Сверхбольшие таблицы
Alexander Goldun ...
Не понял вопроса. А в чем сомнения? Сейчас попробовал дропнуть
Пожалуй, дропанье статистики дало не очень показательный пример. Вот
имел честь наблюдать как расхождение, так и исправление. Вызвал по
другой базе следующее
call sa_get_histogram ('store_id','store_movement')
Получил для store_id=7 величину 0.0028850038
А результат такого запроса:
SELECT cast((select count(*) from store_movement where store_id=7)as
double)/ (select count(*) from store_movement)
вернул 0.0030593773
И этот же запрос подкорректировал величину - второй вызов
sa_get_histogram показал уже исправленное значение 0.0030593773
Это слишком просто. Выполни запрос с разными диапазонами, т.е.
store_id between 1 and 100, store_id between 20 and 400, и т.п.,
а потом смотри на статистику. Поправлять по конкретному значению -
не спортивно :)
--
Хорсун Влад
--~--~-~--~~~---~--~~
-~--~~~~--~~--~--~---
Re: Сверхбольшие таблиы
Vlad Horsun пишет: А что ты ожидал там увидеть? Документацию. а не Это же общие фразы, Именно документации предостаточно. А под предвзятостью я имел в виду не столько приверженность к разным серверам, сколько твою позицию, IMHO несколько отличающуюся от позиции пользователя СУБД. Ты все-таки разработчик сервера. Ага. Сколько коннектов, столько и совершено разных приложений с абсолютно разными запросами. Угу. Логично. Ирония непонятна. Даже в рамках однотипных рабочих мест паттерны работы и интересующие данные могут заметно отличаться. Кладовщик склада комплектующих с несколькими тысячами наименований, лежащих на складе, и склад сырья например деревообработки, где лежит всего несколько сортов шпона, клей, смола. Продажники: кто-то работает по одному-двум VIP-клиентам, а кто-то скопом со всеми остальными и т.д. Приложение одно и то же, а вот запросы из одних и тех же форм могут заметно отличаться как по форме, так и по значениям основных параметров отбора. Так что я бы не стал так категорично утверждать подобное: Кеш планов на коннект - это ещё один маразм, косвенно показывающий, что не Всё, всё. Надоело. Тут не форум по о[б]суждению ASA :) Разумеется. Сворачиваюсь. --~--~-~--~~~---~--~~ -~--~~~~--~~--~--~---
Странное поведение GBAK
Уже второй раз натыкаюсь на одно и то же: есть робот, который по расписанию стартует GBAK. Если по какой-то причине места на диске под бэкап не хватило - GBAK не завершается, а остается висеть, при этом робот кушает 100% проца. Кто тут виноват: робот или GBAK, честно говоря не знаю, но поведение странное. Да, файл протокола сохраняется на тот же диск что и бэкап, может в этом дело? --~--~-~--~~~---~--~~ -~--~~~~--~~--~--~---
Re: Странное поведение GBAK
Konstantin R. Beliaev ... Уже второй раз натыкаюсь на одно и то же: есть робот, который по расписанию стартует GBAK. Если по какой-то причине места на диске под бэкап не хватило - GBAK не завершается, а остается висеть, при этом робот кушает 100% проца. gbak ждёт, пока место появится. А что твой робот делает gbak'у неведомо... -- Хорсун Влад --~--~-~--~~~---~--~~ -~--~~~~--~~--~--~---
Re: GBAK
Horsun Vlad wrote: gbak ждёт, пока место появится. ОУ! так его не килять надо, а место освобождать? А я его все в расход пускаю :-))) --~--~-~--~~~---~--~~ -~--~~~~--~~--~--~---
Re:
Dmitri Kuzmenko wrote: причиной накопления версий является неработа сборки мусора. в твоем случае причина скорее всего в длительности работы транзакций. Сделай их короче, тогда версии будут становиться мусором, и будут собираться автоматически. А разве первый ролбэк не тормознет сборку мусора до ближайшего свипа? --~--~-~--~~~---~--~~ -~--~~~~--~~--~--~---
Re: ���������� ������������� ������� ��� BETWEEN, LESS, GREAT � STARTING
Yuri Grabar [EMAIL PROTECTED] wrote: Вычисление результирующей селективности происходит немного станно... При изменении исходной селективности индекса от 0 до 1 вычисленная результирующая селективность изменяется от 0.2 до 1.0. Так точно. Вот только заметно отличаться от 0.2 она будет только при очень низкой селективности индекса. При 0.1 мы получим 0.28, при 0.5 результат будет 0.6. Но это уже ооочень плохие индексы :-) Если такой будет один, то он будет использован. Но если будет лучший, то на этот забъет даже 1.5. Иными словами: да, там действительно не совсем константа, если строго подходить. Но на практике это на жизнь не влияет. Не должна ли результирующая селективность вычисляться хотя бы: scratch[i]-selectivity = selectivity + selectivity * factor; Не должна. См. всю предыдущую дискуссию :-) P.S. В официальный RC3 войдут более оптимистичные оценки (а-ля Оракл). Скорее всего, больше меняться ничего не будет. -- Дмитрий Еманов --~--~-~--~~~---~--~~ -~--~~~~--~~--~--~---
Re: Частообновляемыезаписи
Вопрос: правильно ли я делаю, и как надо делать правильней? У меня была такая же проблема. Сканирую компьютерную сеть предприятия каждые пять минут. После окончания каждого сканирования, удаляю из таблицы DevicesOnline все записи, затем в этой же транзакции добавляю все найденные устройства. В таблице DevicesOnline есть триггер, который изменяет (добавляет) записи в таблице Devices (все устройства). Так вот т.к. при каждом сканировании изменяются все записи в таблице Devices, там тоже накапливалось очень много версий записей и база начинала жутко тормозить. Проблему решил уменьшением Sweep interval - поставил его равным 10. gfix.exe -housekeeping 10 -user SYSDBA -password masterkey server:base --~--~-~--~~~---~--~~ -~--~~~~--~~--~--~---
Re: Re:
Konstantin R. Beliaev ... Dmitri Kuzmenko wrote: причиной накопления версий является неработа сборки мусора. в твоем случае причина скорее всего в длительности работы транзакций. Сделай их короче, тогда версии будут становиться мусором, и будут собираться автоматически. А разве первый ролбэк не тормознет сборку мусора до ближайшего свипа? Нет -- Хорсун Влад --~--~-~--~~~---~--~~ -~--~~~~--~~--~--~---
Re: BETWEEN, LESS, GREAT STARTING
Hello, Dmitry! You wrote on Tue, 27 Jun 2006 13:46:02 +0400: DY Yuri Grabar [EMAIL PROTECTED] wrote: Вычисление результирующей DY селективности происходит немного станно... При ?? изменении исходной селективности индекса от 0 до 1 вычисленная ?? результирующая селективность изменяется от 0.2 до 1.0. DY Так точно. Вот только заметно отличаться от 0.2 она будет только при DY очень низкой селективности индекса. При 0.1 мы получим 0.28, при 0.5 DY результат будет 0.6. Но это уже ооочень плохие индексы :-) Только вот, например, очень хороший индекс с селективностью в 1 миллиардную все равно получит селективность 0.20001. Т.е. , результирующая селективность, какой бы ни была хорошей селективность исходного индекса, все равно будет хуже этой константы. Получается, что чем хуже исходный индекс, тем меньше он теряет в весе по сравнению с более хорошими индексами. Вот это и смущает. DY Если такой будет один, то он будет использован. Но если будет лучший, DY то на этот забъет даже 1.5. DY Иными словами: да, там действительно не совсем константа, если строго DY подходить. Но на практике это на жизнь не влияет. ?? Не должна ли ?? результирующая селективность вычисляться хотя бы: ?? ?? scratch[i]-selectivity = selectivity + selectivity * factor; DY Не должна. См. всю предыдущую дискуссию :-) DY P.S. В официальный RC3 войдут более оптимистичные оценки (а-ля Оракл). DY Скорее всего, больше меняться ничего не будет. Ну, установленные на сегодня значения в 0.025 для between и 0.05 для больше/меньше, конечно, лучше чем были, но все-таки как-то это неправильно... Сам алгоритм вычисления результирующей селективности не очень понятен. -- With best regards, Yuri Grabar. --~--~-~--~~~---~--~~ -~--~~~~--~~--~--~---
Re: GBAK
Konstantin R. Beliaev ... Horsun Vlad wrote: gbak ждёт, пока место появится. ОУ! так его не килять надо, а место освобождать? А я его все в расход пускаю :-))) Я не помню - он или действительно продолжит работу, или он висит ожидая ответа на свой вопрос о следующей ленте. Проверить нужно -- Хорсун Влад --~--~-~--~~~---~--~~ -~--~~~~--~~--~--~---
Re: Сверхбольшие таблицы
Horsun Vlad пишет: Это слишком просто. Выполни запрос с разными диапазонами, т.е. store_id between 1 and 100, store_id between 20 and 400, и т.п., а потом смотри на статистику. Поправлять по конкретному значению - не спортивно :) Посмотрел бегло по гистограмме с большим кол-вом шагов и относительно равномерным распределением. Что-то пересчитывает по задетым диапазонам, похоже не досконально точно, если диапазон запроса охватывает большое число шагов гистограммы. Иногда дробит или наоборот - расширяет границы имеющихся шагов, особенно если увеличение диапазона не приводит к увеличению частоты для него (например увеличение диапазона с отсутствующими записями за счет соседнего). Детально не анализировал и не считал. Могу лишь подтвердить, что оно таки работает :) --~--~-~--~~~---~--~~ -~--~~~~--~~--~--~---
Re: BETWEEN, LESS, GREAT STARTING
Yuri Grabar [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] Ну, установленные на сегодня значения в 0.025 для between и 0.05 для больше/меньше Только 0.0025 для between, а не 0.025. --~--~-~--~~~---~--~~ -~--~~~~--~~--~--~---
Re: GBAK
Horsun Vlad [EMAIL PROTECTED] wrote: Я не помню - он или действительно продолжит работу, или он висит ожидая ответа на свой вопрос о следующей ленте. Проверить нужно Второе, насколько я помню. Он ожидает команды в stdin. -- Дмитрий Еманов --~--~-~--~~~---~--~~ -~--~~~~--~~--~--~---
Re: BETWEEN, LESS, GREAT STARTING
Yuri Grabar [EMAIL PROTECTED] wrote: Только вот, например, очень хороший индекс с селективностью в 1 миллиардную все равно получит селективность 0.20001. Т.е. , результирующая селективность, какой бы ни была хорошей селективность исходного индекса, все равно будет хуже этой константы. Хуже на одну миллиардную. Это критично? Получается, что чем хуже исходный индекс, тем меньше он теряет в весе по сравнению с более хорошими индексами. Вот это и смущает. Ты про разницу в 1.5 раза (по итоговой псевдо-селективности) вместо трех порядков (по начальной селективности)? Дык по хорошему разницы вообще быть не должно, обсуждали ведь это :-) Ты не согласен, но убедить я тебя не могу. -- Дмитрий Еманов --~--~-~--~~~---~--~~ -~--~~~~--~~--~--~---
Re: Частообновляемыезаписи
Проблему решил уменьшением Sweep interval - поставил его равным 10. ...чем озадачил сервер непрерывным свипом. Может, хоть 1000 поставить? Что скажут гуру? к проктологу перемещения 1 тыс сотрудников за два года, запрос на местонахождение человека - мгновенно -- Булычев Алексей http://www.stella-npf.ru --~--~-~--~~~---~--~~ -~--~~~~--~~--~--~---
Re: BETWEEN, LESS, GREAT STARTING
Евгений Килин Только 0.0025 для between, а не 0.025. 1/365 ≈ 0,002739 ИМХО, это и есть источни оракловского оптимизьма -- Булычев Алексей http://www.stella-npf.ru --~--~-~--~~~---~--~~ -~--~~~~--~~--~--~---
Re: Частообновляемыезаписи
Дмитрий [EMAIL PROTECTED] сообщил/сообщила в новостях следующее: news:[EMAIL PROTECTED] Проблему решил уменьшением Sweep interval - поставил его равным 10. В справке IBAnalyst (и не только там) написато, что лучше выставлять свип интервал в ноль, то есть совсем отключать автосборку мусора, и делать свип ручками, например ночью в воскресенье. Я так и сделал. --~--~-~--~~~---~--~~ -~--~~~~--~~--~--~---
OFF: good many photo
http://debri.ru/c/liven_26062006_foto/ --~--~-~--~~~---~--~~ -~--~~~~--~~--~--~---
Re: Re:
Konstantin R. Beliaev [EMAIL PROTECTED] сообщил/сообщила в новостях следующее: news:[EMAIL PROTECTED] А разве первый ролбэк не тормознет сборку мусора до ближайшего свипа? При записи точек я не делаю ролбэк. --~--~-~--~~~---~--~~ -~--~~~~--~~--~--~---
Re: BETWEEN, LESS, GREAT STARTING
Boulitchev Aleksey [EMAIL PROTECTED] wrote: ИМХО, это и есть источни оракловского оптимизьма На самом деле, это 0.05 * 0.05 :-) А вот откуда они взяли эти 0.05, действительно интересно. -- Дмитрий Еманов --~--~-~--~~~---~--~~ -~--~~~~--~~--~--~---
Re: Частообновляемыезаписи
Korg [EMAIL PROTECTED] writes: Дмитрий dich at iname.ru сообщил/сообщила в новостях следующее: news:loom.20060627T095956-526 at post.gmane.org... Проблему решил уменьшением Sweep interval - поставил его равным 10. В справке IBAnalyst (и не только там) написато, что лучше выставлять свип интервал в ноль, то есть совсем отключать автосборку мусора, и делать свип ручками, например ночью в воскресенье. Я так и сделал. Когда свип интервал был установлен у меня равным нулю, программа сканирующая сеть могла работать менее 2 суток. Т.к. после этого начавшаяся транзакция ещё не успевала завершиться до момента старта следующей. На обновление данных у меня в программе отведено 2 минуты (сканирование - каждые 5 минут). И как я думаю из-за большого числа версий всех записей в таблице Devices, транзакция не успевала отрабатывать. Это всего лишь моё предположение, возможно кто-либо подтвердит или опровергнет его. --~--~-~--~~~---~--~~ -~--~~~~--~~--~--~---
TRADING CALLS - NIFTY FUTURES MARUTI UDYOG.
WWW.DERIVATIVEMASTER.COM [ 27 th JUNE 2006 ] Todays calls were as under : Nifty Master Subscription Plan Reccommendation Suggested Lot Size Profit / (Loss) Buy Nifty Futures @ 2885 SL 2867 Target 2964 200 (100*2) + 15,800 Futures Master Subscription Plan Reccommendation Suggested Lot Size Profit / (Loss) Per Lot Buy Maruti Futures @ 716 SL 711 Target 734 800 + 14,400 To Subscribe visit www.DerivativeMaster.com OR Mail at [EMAIL PROTECTED] WWW.DERIVATIVEMASTER.COM --~--~-~--~~~---~--~~ -~--~~~~--~~--~--~---
Re: FDB to MDB/TXT
А венгерский есть? Дмитрий --~--~-~--~~~---~--~~ -~--~~~~--~~--~--~---
Re: good many photo
http://debri.ru/c/liven_26062006_foto/ Уй-йо, впечатляет. А вот интересно. Вроде как должна быть дождевая канализация... With b/r. Gleb. --~--~-~--~~~---~--~~ -~--~~~~--~~--~--~---
Re: FDB to MDB/TXT
Dmitry Lendel wrote: А венгерский есть? Без понятия. -- Regards. Ded. --~--~-~--~~~---~--~~ -~--~~~~--~~--~--~---
Re: Частообновляемыезаписи
Дмитрий Когда свип интервал был установлен у меня равным нулю, программа сканирующая сеть могла работать менее 2 суток. Т.к. после этого начавшаяся транзакция ещё не успевала завершиться до момента старта следующей. На обновление данных у меня в программе отведено 2 минуты (сканирование - каждые 5 минут). И как я думаю из-за большого числа версий всех записей в таблице Devices, транзакция не успевала отрабатывать. Это всего лишь моё предположение, возможно кто-либо подтвердит или опровергнет его. это какой-то товарищъ держит открытую транзакцию. на моих базах свип - 0, интерактивные клиенты коммитят на каждый чих, транзакции из нескольких операторов довольно редки автоматы (они же роботы), которые молотят в реалтайме коммитят после каждого запроса, при простое более 10 мин отваливают от базы вообще, после каждой тысячи запросов переподключаются (из-за глюка с утечкой памяти при неполном фетче из ХП) ессно пул коннектов, дабы не подвисать на подключениях -- Булычев Алексей http://www.stella-npf.ru --~--~-~--~~~---~--~~ -~--~~~~--~~--~--~---
Re: good many photo
Мадорский Г.В. [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] http://debri.ru/c/liven_26062006_foto/ А вот интересно. Вроде как должна быть дождевая канализация... В ней обычно песка и мусора столько, что она своих функций не выполняет. --~--~-~--~~~---~--~~ -~--~~~~--~~--~--~---
Re: Сверхбольшие таблиы
Vlad Horsun пишет: И кто его знает, когда ASA решит его из кеша выкинуть Если разработчики признаются - расскажу. Когда факт выполнения будет сильно отличаться от плана. Но это уже поздно, т.к. плохое выполнение запроса уже произошло. Ответил Glenn Paulley (Research and Development Manager, Query Processing, iAnywhere Solutions Engineering): The server monitors the access plan used for a query in a stored procedure, and if the same plan is used 10 times in a row, that plan is cached and is used for the 11th execution. Periodically, on a logarithmic scale, the query is re-optimized and the plan is compared to the previous one. If it is still the same, the cached plan continues to be used. Queries will be reoptimized at least every 640 times (that is the end of the log scale). A plan cache is abandoned when - user disconnects - any schema modification - any reset of any option setting --~--~-~--~~~---~--~~ -~--~~~~--~~--~--~---
вырожденный пример, но странно
Hello, All! select table1.* from table1, table2 и select * from table1, table2 Планы совпадают, даже количество fetches from cache cовпадает. Почему FB не удаляет table2 из первого запроса нафиг? Таблицы НИКАК не связаны между собой. -- WinAMP://none: WinAMP is suffocated http://Arioch.nm.ru/FL/Fidolook_SL.png Mail: the)under(Arioch)at(nm)dot(ru ICQ: xmpp:[EMAIL PROTECTED] --~--~-~--~~~---~--~~ -~--~~~~--~~--~--~---
Еще вырожденный пример, derived tables
Hello, All! Хотелось поиграться и сравнить Попробовал сделать аналог обычного inner join / left join (на этих таблицах разницы нет (not null, unique)) select v.* from dic_attr_values v, ( select title from dic_attr a where a.id = v.id_a) as a2(title) - error: unknown column v.id_a Понял, если бы было unknown table v, но... Значит так нельзя. Жаль... Попробуем через гланды: =Beginning of the citation== select distinct v2.*, a2.* from dic_attr_values v2, ( select a.title, v.id_a from dic_attr a, dic_attr_values v where a.id = v.id_a) as a2(title, id_a) where v2.id_a = a2.id_a =The end of the citation Результат такой же как нормальный join, но чтения зашкалили =Beginning of the citation== select distinct v2.*, a2.* from dic_attr_values v2, ( select a.title, v.id_a, v.id_v from dic_attr a, dic_attr_values v where a.id = v.id_a) as a2(title, id_a, id_v) where v2.id_a = a2.id_a and v2.id_v = a2.id_v =The end of the citation Меньше чтений ,но все равно многовато. =Beginning of the citation== Адаптированный план PLAN SORT (JOIN (A2 A NATURAL, A2 V INDEX (FK_DIC_ATTR_VALUES), V2 INDEX (PK_DIC_ATTR_VALUES))) =The end of the citation зачем два раза по A2 бежать ? Таблички - 5 строк и 5x5 строк, останки от старой попытки решить задачу Эйнштейна еще на demo.ru :-) =Beginning of the citation== CREATE TABLE DIC_ATTR ( ID T_ID, /* smallint*/ TITLE T_DESCR /* какая-то небольшая строка */ ); ALTER TABLE DIC_ATTR ADD CONSTRAINT PK_DIC_ATTR PRIMARY KEY (ID); CREATE TABLE DIC_ATTR_VALUES ( ID_A T_ID, ID_V T_ID, TITLE T_DESCR ); ALTER TABLE DIC_ATTR_VALUES ADD CONSTRAINT PK_DIC_ATTR_VALUES PRIMARY KEY (ID_A, ID_V); ALTER TABLE DIC_ATTR_VALUES ADD CONSTRAINT FK_DIC_ATTR_VALUES FOREIGN KEY (ID_A) REFERENCES DIC_ATTR (ID); =The end of the citation FB2 rc2 После заявлений о поддержке derived tables в release notes, думал что такие вырожденные примеры Firebird отщелкает. Или это я в 4 часа ночи выродился и нифига не понимаю? -- WinAMP://none: WinAMP is suffocated http://Arioch.nm.ru/FL/Fidolook_SL.png Mail: the)under(Arioch)at(nm)dot(ru ICQ: xmpp:[EMAIL PROTECTED] --~--~-~--~~~---~--~~ -~--~~~~--~~--~--~---
Re: вырожденный пример, но странно
28.06.06 в 03:34 Arioch /BDV/ в своём письме писал(а): select table1.* from table1, table2 и select * from table1, table2 Почему FB не удаляет table2 из первого запроса нафиг? Таблицы НИКАК не связаны между собой. Я тормоз. Обычное декартово произведение. Впрочем, если добавить distinct - то мог бы и удалять :) -- Написано в почтовом клиенте браузера Opera: http://www.opera.com/mail/ --~--~-~--~~~---~--~~ -~--~~~~--~~--~--~---
Derived tables bug?
Hello, All! select count(*) from (select count(some_field) from some_table where id=31) Invalid token. Dynamic SQL Error. SQL error code = -104. Invalid command. COLUMN 1 is specified without a name. Должен бы по идее вернуть единичку. Смысла в запросе немного, но, тем не менее... Удач -- Alexander A. Venikov, Tobolsk, Russia Real e-mail address is venixangry_dogtndottobdotru --~--~-~--~~~---~--~~ -~--~~~~--~~--~--~---
Re: Derived tables bug?
Hi Alexander A. Venikov ! AAV select count(*) from AAV (select count(some_field) from some_table where id=31) вот же: AAV COLUMN 1 is specified without a name. select count(*) from (select count(some_field) from some_table where id=31) as aaa(id) - --~--~-~--~~~---~--~~ -~--~~~~--~~--~--~---
Re: Derived tables bug?
Hello, Alexander! You wrote to All on Wed, 28 Jun 2006 08:48:13 +0600: select count(*) from (select count(some_field) as some_field_count from some_table where id=31) Такой работает. Удач -- Alexander A. Venikov, Tobolsk, Russia Real e-mail address is venixangry_dogtndottobdotru --~--~-~--~~~---~--~~ -~--~~~~--~~--~--~---
Re: Derived tables bug?
Alexander A. Venikov [EMAIL PROTECTED] wrote: Должен бы по идее вернуть единичку. Смысла в запросе немного, но, тем не менее... Не баг, а скорее недоработка. Уже обращалось на это внимание, но правиться в 2.0 не будет. -- Дмитрий Еманов --~--~-~--~~~---~--~~ -~--~~~~--~~--~--~---
Re: ��� ����������� ������, derived tables
Arioch /BDV/ [EMAIL PROTECTED] wrote: Значит так нельзя. Жаль... Учи матчасть. зачем два раза по A2 бежать ? Что написал, то и получил. После заявлений о поддержке derived tables в release notes, думал что такие вырожденные примеры Firebird отщелкает. Или это я в 4 часа ночи выродился и нифига не понимаю? Шел бы ты спать. -- Дмитрий Еманов --~--~-~--~~~---~--~~ -~--~~~~--~~--~--~---
Re: BETWEEN, LESS, GREAT STARTING
Yuri Grabar [EMAIL PROTECTED] wrote: ?? все равно будет хуже этой константы. DY Хуже на одну миллиардную. Это критично? Дим, она хуже не на 1 миллиардную, а на 0.20001 - 1 миллиардная... Можно еще в процентах посчитать, только все равно будет, что лучшие индексы проигрывают много больше, чем худшие. Ничего не понимаю. Ты пишешь: хуже этой константы. Таковая у нас одна - 0.2. Итоговая селективность - 0.2001. Я ни фига не вижу, как, для чего и в каких процентах лучшие индексы вдруг будут проигрывать худшим. по нему никто и индекс строить не будет. А даже если он есть, то его всегда можно +0 погасить. Заставить же использовать кроме ручного планирования способа нет. Т.е. таки rule-based оптимизатор? Нет уж, извини, не согласная я (с) -- Дмитрий Еманов --~--~-~--~~~---~--~~ -~--~~~~--~~--~--~---
Re: BETWEEN, LESS, GREAT STARTING
Ребята, а расскажите что такое руле-бейзед оптимизатор? --~--~-~--~~~---~--~~ -~--~~~~--~~--~--~---
Re: Derived tables bug?
Hello, Dmitry! You wrote on Wed, 28 Jun 2006 07:36:46 +0400: DY Не баг, а скорее недоработка. Уже обращалось на это внимание, DY но правиться в 2.0 не будет. Сложно? Не под шкуру лезу, просто любопытно. Удач -- Alexander A. Venikov, Tobolsk, Russia Real e-mail address is venixangry_dogtndottobdotru --~--~-~--~~~---~--~~ -~--~~~~--~~--~--~---
FB2 - измена с кодировками
Привет всем. В FB2 размер буфера (XSQLVAR::sqllen) под текстовые колонки вычисляется по формуле (размер колонки в символах) умножить на (размер символа в байтах для текущей кодовой страницы подключения) Если кодовая страница подключения - NONE, то берется родная кодировка колонки Если колонка имеет кодировку OCTETS, то считается что символ это байт и кодировка подключения как таковая не учитывается. Собственно измена, в моем понимании, состоит в том, что этот алгоритм распространяется в том числе и на системные таблицы, для колонок которых используется UNICODE_FSS. Раньше эти колонки имели фактичеческую кодировку OCTETS, то есть их размер не зависил ни от чего и был, зачастую, равен 31 байт. Теперь вот поправили, и теперь размер буфера для загрузки этих колонок будет гулять по вышеуказанным правилам. Аминь. Коваленко Дмитрий. www.ibprovider.com --~--~-~--~~~---~--~~ -~--~~~~--~~--~--~---
