Вы не поняли, повторю.
Допустим есть в таблице 1 записей.
Если я строю по ней индекс, то в индекс будут добавлены все записи из
таблицы, т.е. все 1.
Мне нужно поострить индекс в который будут добавлены, например только 7%, от
общего количества записей. Просто остальные записи для
To: ru-firebird@googlegroups.com
Subject: Re: ИндексЫ
19.09.2011 14:33, Михаил Викторович пишет:
Мне нужно поострить индекс в который будут добавлены, например только 7%,
от
общего количества записей. Просто остальные записи для поиска по этому
индексу не нужны. Наличие не нужных записей в
Подскажите можно сделать индекс не полю а например на основании udf, которая
будет обрабатывать блоб?
Можно сделать так что бы не все записи добавлялась в индекс?
Ответ на вопрос зачем: например в таблице очень много записей и нужно
искать только небольшое количество по специфичному индексу,
Все не правильно
Пример: наверное дальше сам сообразишь.
CREATE OR ALTER PROCEDURE COPYORDER (
fromcdorder integer,
tocdorder integer,
flags integer = 0)
as
declare variable cdthing integer;
declare variable cdmsh integer;
declare variable comment varchar(255);
declare variable price
Т.е. анализ планов запросов ниасилили?
Ну разве мы могли об этом сами догадаться? Спасибо вы сейчас посеяли в нас
столь исключительную своей оригинальностью мысль. :)
На самом деле есть опредлённые проблемы у оптимизатора когда он выбирает
сливание битовых карт индексов на сверхбольшых
Так тут дело не во вставке а в общем торможении сервера (ЦПУ, винт,
память) при большой нагрузке.
Это верно.
Если это суперсервер, то естественно большое количество кривых селектов
O да Вы оказывается экстрасенс.
Прям предсказатель :-D
А то :)
Подскажите в IB была такая фигня, если в индексе низкая селективность, то
вставка начинала очень сильно тормозить, получалось что при вставке IB
просматривает все одинаковые значения ключа и только потом делает вставку в
конце, для борьбы с этим делали
Подскажите в IB была такая фигня, если в индексе низкая селективность,
то
вставка начинала очень сильно тормозить, получалось что при вставке IB
просматривает все одинаковые значения ключа и только потом делает вставку
в
конце, для борьбы с этим делали составные ключи добавляя в них
В итоге все равно будет перегрузка по производительности. Решение с архивом
верное. Теперь когда проектирую новые системы сразу предусматриваю
архивирование. Хотя есть еще вариант, например копим данные за 10 лет потом
начинаем стирать, тем самым получаем более менее постоянный объем базы, без
Тем не менее для более дельных рекомендаций ...
А зачем мне Ваши рекомендации? Разве их я спрашивал?
Я написал свое мнение о том, что человек прав, придя к идее архива. На счет
реализации на триггерах и использования передачи в другую базу возможно вам
видней, такой вариант пока не использовал и
А про какую версию FB идет речь? Вопрос весьма интересный.
From: ru-firebird@googlegroups.com [mailto:ru-firebird@googlegroups.com] On
Behalf Of Andrei
Sent: Monday, January 31, 2011 4:32 PM
To: ru-firebird@googlegroups.com
Subject: Re: Внешние процедуры и триггеры в ФБ 3.0
вопрос снят.
Искал на работу людей.
Взрослых вообще нет. А если есть то сразу 'начальник при этом парадокс сам
ничего никогда не делал и умел и сразу рулить. Или другой вариант дети
просятся и денег хотят кучу а сами из себя даже не ноль а null :)
Нашел старого знакомого, кое как уговорил, ему 50, человека с
Факт. Был счастлив когда уговорил пойти работать ко мне товарища которому
скоро 50. Другого человека с более универсальными знаниями и способного
разобраться в чем угодно я не знаю.
Ну и объективно технологии устаревают - сейчас на дельфи разработчика
вменяемого найти, это как на коболе
Формат даты у тебя для меня какой то странный.
А просто запрос
Select cast('1980-01-01' as date) from rdb$databasename
Работает?
-Original Message-
From: ru-firebird@googlegroups.com [mailto:ru-fireb...@googlegroups.com] On
Behalf Of Миша [НКвД]
Sent: Saturday, February 27, 2010 3:06
14 matches
Mail list logo
