Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Microsoft SQL Server Новый топик    Ответить
Топик располагается на нескольких страницах: [1] 2   вперед  Ctrl      все
 А что вы за табличную UDF думаете как за средство прятать часть запроса от оптимизатора?  [new]
Crimean
Member

Откуда:
Сообщений: 13147
Я вот пользовал "долго и щасливо" пока не начал нарываться на вот такое
https://connect.microsoft.com/SQLServer/feedback/details/721290/multi-statement-udf-in-join-query-executed-as-apply-depends-data-distribution
это чтобы долго не рассказывать.
Поскольку англицкий у меня корявый - рассказываю на нативном языке - есть представление, в нем таблица фильтруется при помощи табличной UDF с PRIMARY KEY в резульаттах. Все вроде бы "честно". И в большинстве случаев все действительно красиво, но временами сервер то бешено спулить начинает то делает вид, что ему APPLY померещился и выполняет UDF кучу раз, хотя поводов ему никто не давал. Обходы, конечно, есть, но надоело уже ловить такие расклады - а они зависят от распределения данных и хинтами подпирать..
А оверхед на железо безумный поскольку речь идет про тысячи вызовов недешевой UDF или про многомиллионный спулинг
28 янв 12, 16:16    [11989109]     Ответить | Цитировать Сообщить модератору
 Re: А что вы за табличную UDF думаете как за средство прятать часть запроса от оптимизатора?  [new]
aleks2
Guest
На Солнце тоже есть пятна....
28 янв 12, 16:27    [11989135]     Ответить | Цитировать Сообщить модератору
 Re: А что вы за табличную UDF думаете как за средство прятать часть запроса от оптимизатора?  [new]
Crimean
Member

Откуда:
Сообщений: 13147
aleks2
На Солнце тоже есть пятна....


уважаемый, вам в "солнце", а не в "sql server"
p.s.
проблема, оказывается, имеет место быть начиная с 2000 сиквела
28 янв 12, 16:34    [11989150]     Ответить | Цитировать Сообщить модератору
 Re: А что вы за табличную UDF думаете как за средство прятать часть запроса от оптимизатора?  [new]
Mnior
Member

Откуда: Кишинёв
Сообщений: 6724
Во всем виновата императивщина
Инлайн ...
28 янв 12, 16:40    [11989161]     Ответить | Цитировать Сообщить модератору
 Re: А что вы за табличную UDF думаете как за средство прятать часть запроса от оптимизатора?  [new]
Crimean
Member

Откуда:
Сообщений: 13147
блин, сегодня чо, внеочередное собрание КО на форуме? не знал - предупреждайте
28 янв 12, 16:42    [11989173]     Ответить | Цитировать Сообщить модератору
 Re: А что вы за табличную UDF думаете как за средство прятать часть запроса от оптимизатора?  [new]
ChA
Member

Откуда: Москва
Сообщений: 11314
Crimean
Я вот пользовал "долго и щасливо" пока не начал нарываться на вот такое
https://connect.microsoft.com/SQLServer/feedback/details/721290/multi-statement-udf-in-join-query-executed-as-apply-depends-data-distribution
Стараюсь избегать MSUDF, поелику возможно. Фактически это эквивалентно материализации, но тогда лучше сразу во временную таблицу или табличную переменную, а потом их в запрос. Хотя тоже приходилось как-то HASH-ем подпирать. Но в чём, собственно, вопрос-то ? WA вроде ты и сам успешно юзаешь.

P.S. SQL2K.
29 янв 12, 14:23    [11991402]     Ответить | Цитировать Сообщить модератору
 Re: А что вы за табличную UDF думаете как за средство прятать часть запроса от оптимизатора?  [new]
ChA
Member

Откуда: Москва
Сообщений: 11314
Кстати, вспомнил, что помогало иногда выставить её в начале FROM, но это не всегда удобно.
29 янв 12, 14:25    [11991418]     Ответить | Цитировать Сообщить модератору
 Re: А что вы за табличную UDF думаете как за средство прятать часть запроса от оптимизатора?  [new]
Mnior
Member

Откуда: Кишинёв
Сообщений: 6724
Crimean, да поставим мы +1, не бойтесь. Но лично у меня не особо было желание это исправлять на месте MS - специфично и сложно распыляться на безперспективные вещи.

Намного полезнее выяснить что там у вас такое что:
1. table-valued нельзя в инлайн запихнуть
2. первоначальный запрос выпадает (до создания TVF)
3. нельзя упростить систему/запрос (изменив/добавив нужной структурной инфы: ключи, ограничения ...)
4. нельзя постоянные одни и теже вычисления в запросах (CPU) перенести в индексированные представления (Memory)

Проблемы надо решать, а не решать почему обходные костыли не всегда работают.

Вы же не тупой пользователь тулзы MSSQL, вы участник сообщества разработчиков информационных систем, вы же также участвуете в разработке языка и информационной среды. У нас же у всех есть модель как будут разрабатываться и декларироваться системы и как будет работать компилятор, через 5, 10 и 100 лет. Но главное, как мы будем декларировать системы и на кикие вещи обращать в первую очередь. Это наша задача (нашей профессии) и никого другого.

Ваш, КО.
29 янв 12, 14:51    [11991517]     Ответить | Цитировать Сообщить модератору
 Re: А что вы за табличную UDF думаете как за средство прятать часть запроса от оптимизатора?  [new]
Mnior
Member

Откуда: Кишинёв
Сообщений: 6724
PS: Crimean, а почему так получилось, что почти все ваши feedback-и помечаны как Closed as Won't Fix ?
29 янв 12, 14:59    [11991540]     Ответить | Цитировать Сообщить модератору
 Re: А что вы за табличную UDF думаете как за средство прятать часть запроса от оптимизатора?  [new]
Crimean
Member

Откуда:
Сообщений: 13147
Mnior
PS: Crimean, а почему так получилось, что почти все ваши feedback-и помечаны как Closed as Won't Fix ?


по-моему не по адресу вопрос. мне еще за мс отдуваться не хватало
30 янв 12, 01:31    [11993597]     Ответить | Цитировать Сообщить модератору
 Re: А что вы за табличную UDF думаете как за средство прятать часть запроса от оптимизатора?  [new]
Lepsik
Member

Откуда: glubinka
Сообщений: 4256
Crimean
Поскольку англицкий у меня корявый - рассказываю на нативном языке - есть представление, в нем таблица фильтруется при помощи табличной UDF с PRIMARY KEY в резульаттах.


ты бы на пальцах - то бишь на sql бы показал
30 янв 12, 06:46    [11993757]     Ответить | Цитировать Сообщить модератору
 Re: А что вы за табличную UDF думаете как за средство прятать часть запроса от оптимизатора?  [new]
Crimean
Member

Откуда:
Сообщений: 13147
Lepsik
ты бы на пальцах - то бишь на sql бы показал


а там по ссылке на коннект есть и простое репро и варианты обхода :)

странно, что в обходе с APPLY он работает только после указания TOP 1 при том что объявлен PRIMARY KEY
беда не в описанной ситуации, а когда схема данных не позволяет писать JOIN, а заставляет писать IN / EXISTS - тут уже ничем не подопрешь (APPLY / HASH). внешне появляется подозрение, что оптимизатору пофик наличие PRIMARY / UNIQUE на табличных переменных

да! работает на всех версиях 2000 - R2, так что формально это поведение BY DESIGN
30 янв 12, 11:50    [11995078]     Ответить | Цитировать Сообщить модератору
 Re: А что вы за табличную UDF думаете как за средство прятать часть запроса от оптимизатора?  [new]
Mnior
Member

Откуда: Кишинёв
Сообщений: 6724
Crimean
внешне появляется подозрение, что оптимизатору пофик наличие PRIMARY / UNIQUE на табличных переменных
Ёпт.
Есть такая мячта, собрать все-все-все-все баги и ссылки на форумы связанные с тем что статистика у оптимизатора важнее банальной логики структуры, с расжёвыванием по полочкам. И запендёрить массовый флуд в connection, что пора MS поменять эту тупорылую политику оптимизатора.

Мячты-мячты ... время и мозги нужны, но главное же участие всего сообщества разрабов.
30 янв 12, 13:33    [11995915]     Ответить | Цитировать Сообщить модератору
 Re: А что вы за табличную UDF думаете как за средство прятать часть запроса от оптимизатора?  [new]
Crimean
Member

Откуда:
Сообщений: 13147
есть лучше поводы для флуда. к примеру набившая уже ситуация с компиляцией планов хранимок
я даже ответ знаю - используйте план гайды.. волшебники, блин, они хоть раз это пробовали на реальных запросах сделать, интересно мне..
30 янв 12, 13:40    [11995996]     Ответить | Цитировать Сообщить модератору
 Re: А что вы за табличную UDF думаете как за средство прятать часть запроса от оптимизатора?  [new]
Mind
Member

Откуда: Лучший город на Земле
Сообщений: 2322
Crimean
А оверхед на железо безумный поскольку речь идет про тысячи вызовов недешевой UDF или про многомиллионный спулинг

Откуда по вашему оптимизатор знает, что UDF недешевая? Из того что я вижу стоимость вызова процедуры оценивается в 0.0032, что весьма немного и сделать сотню другую вызовов абсолютно не проблема. Планы построенные на этом знании весьма неплохие.

Я не совсем понимаю чего вы хотите от оптимизатора? Он не видит логики внутри функции и не может оценить её стоимость. На выходе такой функции всегда 1 строка. Вы же сами спрятали часть запроса от оптимизатора, а теперь хотите чтобы он её учел при построении плана? Можно конечно долго спорить о неправильной реализации MSUDF майкрософтом, но такое поведение было изначально и оно вполне логично.

Если вас не пугают перекачивания данных во временные объекты (как в функции), то тогда уж лучше в основной процедуре вместо вызова функции залить данные во временную таблицу, тогда эстимейты будут ближе к реальным при этом часть логики все равно останется "спрятана".
31 янв 12, 04:13    [12000466]     Ответить | Цитировать Сообщить модератору
 Re: А что вы за табличную UDF думаете как за средство прятать часть запроса от оптимизатора?  [new]
Mind
Member

Откуда: Лучший город на Земле
Сообщений: 2322
Mnior
Crimean
внешне появляется подозрение, что оптимизатору пофик наличие PRIMARY / UNIQUE на табличных переменных
Ёпт.
Есть такая мячта, собрать все-все-все-все баги и ссылки на форумы связанные с тем что статистика у оптимизатора важнее банальной логики структуры, с расжёвыванием по полочкам. И запендёрить массовый флуд в connection, что пора MS поменять эту тупорылую политику оптимизатора.

Мячты-мячты ... время и мозги нужны, но главное же участие всего сообщества разрабов.

Я готов поддержать подобную инициативу.

Сам недавно наткнулся на проблему со статистикой, когда при объединении огромной таблицы фактов с небольшими lookup-таблицами (менее 500 строк, это обязательное условие) эстимейты плывут до 50%. При чем каждый дополнительный JOIN ухудшает оценки все больше. В итоге может получится, что вместо реальных 10 миллионов ожидается всего 1-2. Даже тикет завел на коннекте, обещали пересмотреть, ага, как же, так я и поверил. И тоже проблема из-за того, что статистическая модель кривая изначально (с самых первых версий сервера), а костыли в виде предопределенных FK, PK использовать не хотим. Хотя объясните мне, на кой собирать детальную статистику распределения для первичного ключа и потом пытатся её использовать ? Ежу понятно что все значения уникальны.

Кстати в оракле при построении и сборе статистики можно указать дополнительные опции, для случаев если статистика skewed, но в МС как-то не торопятся делать такие изменения, они видать с точки зрения маркетинга бесперспективны.
31 янв 12, 04:46    [12000471]     Ответить | Цитировать Сообщить модератору
 Re: А что вы за табличную UDF думаете как за средство прятать часть запроса от оптимизатора?  [new]
Mnior
Member

Откуда: Кишинёв
Сообщений: 6724
Mind
На выходе такой функции всегда 1 строка. Можно конечно долго спорить о неправильной реализации MSUDF майкрософтом, но такое поведение было изначально и оно вполне логично.
Проблема в том что он вызывает 100500 раз функцию с теми же параметрами, из-за того что закинул её в "конец" плана. Словно её вызов ничего не стоит. Даже для скалярок это засада. Т.е. для исполняемых типов (скаляры и табле-валуед) нужно "до последней капли крови" пихать в "начало" планов.
Вот во строками они такуб засаду сделали (сначало scalar, а потом фильтр), а с этими нифига.

Давно пора опен соорс модели оптимизатора писать.

Кста есть опция ForceSeek.

На счёт ключей - сам нарывался, что он вместо SEEK по кластрному делался FULL SCAN без предиката, а предикат был засунут гдето там аж в LOOP-е (убиться аб стену).

Mind
Если вас не пугают перекачивания данных во временные объекты
А в планах же есть механизмы кэширования результатов. Вот конечно нельзя ими управлять.

Mind
Сам недавно наткнулся на проблему со статистикой, когда при объединении огромной таблицы фактов с небольшими lookup-таблицами (менее 500 строк, это обязательное условие) эстимейты плывут до 50%. При чем каждый дополнительный JOIN ухудшает оценки все больше. В итоге может получится, что вместо реальных 10 миллионов ожидается всего 1-2.

Даже тикет завел на коннекте, обещали пересмотреть, ага, как же, так я и поверил. И тоже проблема из-за того, что статистическая модель кривая изначально (с самых первых версий сервера),

а костыли в виде предопределенных FK, PK использовать не хотим. Хотя объясните мне, на кой собирать детальную статистику распределения для первичного ключа и потом пытатся её использовать ? Ежу понятно что все значения уникальны.

Кстати в оракле при построении и сборе статистики можно указать дополнительные опции, для случаев если статистика skewed, но в МС как-то не торопятся делать такие изменения, они видать с точки зрения маркетинга бесперспективны.
Чёта на вечер ваш слэнг как китайская грамота. Нам смертным до такого пока далеко.
Ссори, а можно чуть проще и где-то подробнее и по русски.
31 янв 12, 20:40    [12007321]     Ответить | Цитировать Сообщить модератору
 Re: А что вы за табличную UDF думаете как за средство прятать часть запроса от оптимизатора?  [new]
SomewhereSomehow
Member

Откуда: Moscow
Сообщений: 2480
Блог
Хотелось бы задать несколько уточняющих вопросов.
Mind
Сам недавно наткнулся на проблему со статистикой, когда при объединении огромной таблицы фактов с небольшими lookup-таблицами (менее 500 строк, это обязательное условие) эстимейты плывут до 50%. При чем каждый дополнительный JOIN ухудшает оценки все больше.
Оценки плывут ввиду актуально статистики, в этом проблема? И сколько в итоге джойнов? Мне было бы интересно для сравнения. Кстати, раз "факты/измерения" стало быть олап, может быть вас спасут радикальные меры в виде column store indexes, а не какие-то местячковые подкрутки статистик?
Mind
Даже тикет завел на коннекте, обещали пересмотреть, ага, как же, так я и поверил.
Можно ссылку, чтобы быть в теме?
Mind
И тоже проблема из-за того, что статистическая модель кривая изначально (с самых первых версий сервера),
Опять же, пожалуйста, аргументируйте, что криво? Вам не нравится как собирается статистика? Насколько я читал, там используется вариация алгоритма maxdiff, для определения наиболее статистически ценных значений (может мой источник ошибается, так что поправьте если у кого другая инфа), и конечно проблемы есть, может проблема в том, что точность в 200 шагов в гистограмме не отражает ваших конкретных распределений. Тогда вопрос уточняется, вам не нравится сам алгоритм, точность или "вы нихера не понимаете в статистике, ее надо собирать по другому"?
Mind
а костыли в виде предопределенных FK, PK использовать не хотим. Хотя объясните мне, на кой собирать детальную статистику распределения для первичного ключа и потом пытатся её использовать ? Ежу понятно что все значения уникальны.
Вот тут кстати да, есть вопросы, но опять же, например проверку внешних и первичных ключей оптимизатор использует, при генерации планов, использует проверку чек констрейнтов. Так что давайте свои примеры (может они совпадут с моими, я тоже иногда не понимаю, почему он не пользуется знаниями, которые у него есть).
Mind
Кстати в оракле при построении и сборе статистики можно указать дополнительные опции, для случаев если статистика skewed, но в МС как-то не торопятся делать такие изменения, они видать с точки зрения маркетинга бесперспективны.
Это видимо имеется ввиду нетипичная статистика. Когда разраб знает лучше как строить статистику, чем обобщенный алгоритм сервера. Категорически согласен. Была бы полезная штука. Хотя я работаю с ОЛТП системами в основном, и не вижу, где бы я мог применить столь отточенные знания статистики, без лишнего геморроя поддержки для себя. Однако, безусловно, чем гибче, тем лучше. Или вы имеете ввиду нечто совершенно другое?
Mnior
Давно пора опен соорс модели оптимизатора писать.

Эх!! "Не сыпь мне соль на рану"...
Это было бы круто! Но видимо, коммерческая тайна. А ну как враги украдут все алгоритмы и сделают такой же sql server только с блекджеком и шлюхами?
31 янв 12, 21:24    [12007500]     Ответить | Цитировать Сообщить модератору
 Re: А что вы за табличную UDF думаете как за средство прятать часть запроса от оптимизатора?  [new]
Crimean
Member

Откуда:
Сообщений: 13147
SomewhereSomehow
Mind
И тоже проблема из-за того, что статистическая модель кривая изначально (с самых первых версий сервера),
Опять же, пожалуйста, аргументируйте, что криво?


впишусь буквально "по горячим следам"

собираем пример. сори чуть пригрузим журнал

-- drop database a
-- create database a
-- use a

-- drop table a
create table a ( id int identity primary key , flag int not null , c1 char(200) default('111') , c2 char(200) default('222') , c3 char(200) default('333') )
go

create index ia_1 on a( Flag )
go

set nocount on
declare @i int
set @i = 0
begin tran
while @i < 100000 begin
set @i = @i + 1
if @i < 1000 insert into a ( flag ) select @i
else insert into a ( flag ) select 0
end
commit
go


теперь делаем очень простую штуку:

раз

select * into b from a where flag <> 0


два

select 

b.* ,
(select max( len( a.c1 )) from a where a.flag = b.flag) as l

from b


в чем беда? в том, что в подзапросе табличка a сканится вся.
но достаточно добавить and a.flag <> 0 как вуаля - "полный шоколад"
почему создание индексов / статистик и т.п. на табличку b никак не решает проблему?
ну задирает же реально!!
100 000 записей поднять или 1000 - как бы есть за что бороться
и эта проблема древняя и общая для всех табличных соединений
ну и не одна, ясен день
у меня собралась такая коллекция "подпорок", что коллеги, увидев некоторые, начинают сомневаться в здравости происходящего

а добавление create index ia_2 on a ( flag ) include ( c1 ) только добавляет пикантности ситуации. до того (пока букмарки) разница 3 к 8, после - разница 1 к 28
31 янв 12, 23:00    [12007925]     Ответить | Цитировать Сообщить модератору
 Re: А что вы за табличную UDF думаете как за средство прятать часть запроса от оптимизатора?  [new]
Mind
Member

Откуда: Лучший город на Земле
Сообщений: 2322
SomewhereSomehow
Хотелось бы задать несколько уточняющих вопросов.
Mind
Сам недавно наткнулся на проблему со статистикой, когда при объединении огромной таблицы фактов с небольшими lookup-таблицами (менее 500 строк, это обязательное условие) эстимейты плывут до 50%. При чем каждый дополнительный JOIN ухудшает оценки все больше.
Оценки плывут ввиду актуально статистики, в этом проблема? И сколько в итоге джойнов? Мне было бы интересно для сравнения. Кстати, раз "факты/измерения" стало быть олап, может быть вас спасут радикальные меры в виде column store indexes, а не какие-то местячковые подкрутки статистик?

Статистика актуальна, пересчитана с FULLSCAN. Значений меньше 200. Джойнов может быть даже один. Все равно проблема. Да там можно даже и без фактов/измерений. Просто в OLTP системах редко нужно вытаскивать сотни-тысяч записей, соответственно ошибка не выливается в критическую с нехваткой выделенной памяти и сливаниями данных в tempdb для hash join/sort. Даже сам по себе hash join значительно реже испольщуется в транзакционных системах по сравнению с аналитическими.
Но тем не менее в OLTP тоже можно легко воспроизвести этот баг.
SomewhereSomehow
Mind
Даже тикет завел на коннекте, обещали пересмотреть, ага, как же, так я и поверил.
Можно ссылку, чтобы быть в теме?

Легко
http://connect.microsoft.com/SQLServer/feedback/details/717605/incorrect-join-cardinality-estimation
У меня где-то даже был скрипт чтобы пробежать по всем связям между таблицами и проверить статистику на предмет этой ошибки, на копии нашей продакшн базы показывает весьма грустные результаты. Могу выложить если интересно.
SomewhereSomehow
Mind
И тоже проблема из-за того, что статистическая модель кривая изначально (с самых первых версий сервера),
Опять же, пожалуйста, аргументируйте, что криво? Вам не нравится как собирается статистика? Насколько я читал, там используется вариация алгоритма maxdiff, для определения наиболее статистически ценных значений (может мой источник ошибается, так что поправьте если у кого другая инфа), и конечно проблемы есть, может проблема в том, что точность в 200 шагов в гистограмме не отражает ваших конкретных распределений. Тогда вопрос уточняется, вам не нравится сам алгоритм, точность или "вы нихера не понимаете в статистике, ее надо собирать по другому"?

Проблема в том что 200 шагов слишком много, как ни странно :)
Я знаю что алгоритмы сбора статистики весьма сложны и вряд ли можно их как то сильно улучшить минимальными затратами.
SomewhereSomehow
Mind
а костыли в виде предопределенных FK, PK использовать не хотим. Хотя объясните мне, на кой собирать детальную статистику распределения для первичного ключа и потом пытатся её использовать ? Ежу понятно что все значения уникальны.

Вот тут кстати да, есть вопросы, но опять же, например проверку внешних и первичных ключей оптимизатор использует, при генерации планов, использует проверку чек констрейнтов. Так что давайте свои примеры (может они совпадут с моими, я тоже иногда не понимаю, почему он не пользуется знаниями, которые у него есть).

Да, что-то оптимизатор использует, но далеко не все. Скажем при оценке количества строк в результате джойна 2х таблиц он опирается исключительно на гистограммы с этих 2-х таблиц, и ему предельно фиолетово на внешние и первичные ключи, а также на орграничения NOT NULL. Или еще пример, при сборе статистики (на основе сэмпла) по уникальному полю количество значений в диапазоне будет = 10, а количество уникальных значений окажется 3.66. Ну и как это может быть? Если известно что все значения уникальны, то эти 2 числа всегда должны быть одинаковы.
SomewhereSomehow
Mind
Кстати в оракле при построении и сборе статистики можно указать дополнительные опции, для случаев если статистика skewed, но в МС как-то не торопятся делать такие изменения, они видать с точки зрения маркетинга бесперспективны.
Это видимо имеется ввиду нетипичная статистика. Когда разраб знает лучше как строить статистику, чем обобщенный алгоритм сервера. Категорически согласен. Была бы полезная штука. Хотя я работаю с ОЛТП системами в основном, и не вижу, где бы я мог применить столь отточенные знания статистики, без лишнего геморроя поддержки для себя. Однако, безусловно, чем гибче, тем лучше. Или вы имеете ввиду нечто совершенно другое?

Именно это имею ввиду.
1 фев 12, 00:29    [12008359]     Ответить | Цитировать Сообщить модератору
 Re: А что вы за табличную UDF думаете как за средство прятать часть запроса от оптимизатора?  [new]
Mind
Member

Откуда: Лучший город на Земле
Сообщений: 2322
Crimean
в чем беда? в том, что в подзапросе табличка a сканится вся.
но достаточно добавить and a.flag <> 0 как вуаля - "полный шоколад"
почему создание индексов / статистик и т.п. на табличку b никак не решает проблему?
ну задирает же реально!!
100 000 записей поднять или 1000 - как бы есть за что бороться
и эта проблема древняя и общая для всех табличных соединений
ну и не одна, ясен день
у меня собралась такая коллекция "подпорок", что коллеги, увидев некоторые, начинают сомневаться в здравости происходящего

а добавление create index ia_2 on a ( flag ) include ( c1 ) только добавляет пикантности ситуации. до того (пока букмарки) разница 3 к 8, после - разница 1 к 28

Если условие a.flag <> 0 явно не указано, то физически невозможно сделать поиск по индексу ia_1. Остается только 2 варианта, N поисков по кластерному индеску или полный скан, сервер выбирает второе базируясь на стоимостях операторов. Применить же фильтр просто зная значения из другой таблицы это как то на грани фантастики. Максимум что можно определить, так это отношение количества строк между 2-мя этими таблицами, но это никак не поможет сделать физический поиск по условию которого нет.
Или может я не понимаю какой план вы бы хотели увидеть для этого запроса?
1 фев 12, 02:25    [12008596]     Ответить | Цитировать Сообщить модератору
 Re: А что вы за табличную UDF думаете как за средство прятать часть запроса от оптимизатора?  [new]
Crimean
Member

Откуда:
Сообщений: 13147
Mind
Или может я не понимаю какой план вы бы хотели увидеть для этого запроса?


с использованием индекса конечно же )
вопрос - на основании чего можно сделать такой выбор
не всегда получается указать удачное пустое условие как в этом примере
1 фев 12, 02:34    [12008600]     Ответить | Цитировать Сообщить модератору
 Re: А что вы за табличную UDF думаете как за средство прятать часть запроса от оптимизатора?  [new]
Mind
Member

Откуда: Лучший город на Земле
Сообщений: 2322
Mnior
Mind
Если вас не пугают перекачивания данных во временные объекты
А в планах же есть механизмы кэширования результатов. Вот конечно нельзя ими управлять.

Это Table Spool и разновидности? Оно конечно есть, только тогда явно созданные объекты в tempdb уж лучше чем неявно этим самым спулом. Контроля никакого. Я уж не говорю про то что спул льёт данные в произвольном порядке и легко может быть причиной дорогих page splits, даже при SELECT-ах.
С временными таблицами хотя бы знаешь где и когда их создал и какие индексы на них навесил.
Mnior
Mind
Сам недавно наткнулся на проблему со статистикой, когда при объединении огромной таблицы фактов с небольшими lookup-таблицами (менее 500 строк, это обязательное условие) эстимейты плывут до 50%. При чем каждый дополнительный JOIN ухудшает оценки все больше. В итоге может получится, что вместо реальных 10 миллионов ожидается всего 1-2.

Даже тикет завел на коннекте, обещали пересмотреть, ага, как же, так я и поверил. И тоже проблема из-за того, что статистическая модель кривая изначально (с самых первых версий сервера),

а костыли в виде предопределенных FK, PK использовать не хотим. Хотя объясните мне, на кой собирать детальную статистику распределения для первичного ключа и потом пытатся её использовать ? Ежу понятно что все значения уникальны.

Кстати в оракле при построении и сборе статистики можно указать дополнительные опции, для случаев если статистика skewed, но в МС как-то не торопятся делать такие изменения, они видать с точки зрения маркетинга бесперспективны.
Чёта на вечер ваш слэнг как китайская грамота. Нам смертным до такого пока далеко.
Ссори, а можно чуть проще и где-то подробнее и по русски.

Это пожалуй тянет на отдельный пост. Хотя я тут выше привел ссылку на коннект. Там правда все на буржуйском, да и вообще, по русски, по русски, у меня даже клавиатуры русской нет, а вам все на русском подавай :)
1 фев 12, 03:21    [12008619]     Ответить | Цитировать Сообщить модератору
 Re: А что вы за табличную UDF думаете как за средство прятать часть запроса от оптимизатора?  [new]
Mind
Member

Откуда: Лучший город на Земле
Сообщений: 2322
Crimean
Mind
Или может я не понимаю какой план вы бы хотели увидеть для этого запроса?

с использованием индекса конечно же )
вопрос - на основании чего можно сделать такой выбор
не всегда получается указать удачное пустое условие как в этом примере

Скан индекса бессмысленный, поиск невозможен. Как использовать то?
Ну а сервер тем более не знает как его использовать, тупой он :)
1 фев 12, 03:25    [12008622]     Ответить | Цитировать Сообщить модератору
 Re: А что вы за табличную UDF думаете как за средство прятать часть запроса от оптимизатора?  [new]
Crimean
Member

Откуда:
Сообщений: 13147
Mind
Скан индекса бессмысленный, поиск невозможен. Как использовать то?


тупой вариант - оценивать эффективность индекса хотя бы по граничным условиям. для данной ситуации было бы достаточно
1 фев 12, 11:49    [12009824]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: [1] 2   вперед  Ctrl      все
Все форумы / Microsoft SQL Server Ответить