powered by simpleCommunicator - 2.0.59     © 2025 Programmizd 02
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Форумы / Сравнение СУБД [игнор отключен] [закрыт для гостей] / Сравнение механизмов хинтования.
60 сообщений из 60, показаны все 3 страниц
Сравнение механизмов хинтования.
    #37855472
Фотография Ggg_old
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Вопрос по мотивам топика: http://www.sql.ru/forum/actualthread.aspx?tid=950804 ( В каких СУБД хинты носят чисто директивный характер? )

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

В Sybase SA можно хинтовать индексы, задавать вручную статистику распределения значения - хинтовать статистику, менять уровень "заумности" оптимизатора и косвенно влиять на стратегию выполнения (план) запроса через опцию "оптимизировать для OLTP/OLAP/Смешанный режим".

Насколько я слышал, что у DB2 прямых хинтов нет, т.к. считается что оптимизатор шибко умный, но ямогу ошибаться либо мои знания устарели.
У мсскл/азе точно есть хинтование индексов, про возможности хинтования остального не знаю.
У оракла вроде как богатые возможности, но деталей и возможностей не знаю совсем. Про информикс тоже ничего не знаю.
Файрбёрд - ничего не знаю.
...
Рейтинг: 0 / 0
Сравнение механизмов хинтования.
    #37855550
Фотография AmKad
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Ggg_old,

В Oracle хинты синтаксически оформляются как комментарии, при этом если Вы неправильно написали хинт, оптимизатор (компилятор) вам об этом не скажет, а просто проигнорирует его. В Oracle очень богатые возможности хинтования: индексы, способ сканирования индекса, порядок и способ соединения таблиц, трансформации запросов, параллелелизм, проталкивание предикатов, кеширование, возможность задавать параметры оптимизатора и т.д. А так же, что интересно, есть три хинта, меняющих логику выполнения запросов.
...
Рейтинг: 0 / 0
Сравнение механизмов хинтования.
    #37855595
AmKadGgg_old,

В Oracle хинты синтаксически оформляются как комментарии, при этом если Вы неправильно написали хинт, оптимизатор (компилятор) вам об этом не скажет, а просто проигнорирует его. В Oracle очень богатые возможности хинтования: индексы, способ сканирования индекса, порядок и способ соединения таблиц, трансформации запросов, параллелелизм, проталкивание предикатов, кеширование, возможность задавать параметры оптимизатора и т.д. А так же, что интересно, есть три хинта, меняющих логику выполнения запросов.
А что это за хинты меняющие логику выполнения запросов и следовательно меняющие результат выполнения запросов?
...
Рейтинг: 0 / 0
Сравнение механизмов хинтования.
    #37855612
Фотография AmKad
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
логику выполнения запросов,

CHANGE_DUPKEY_ERROR_INDEX
IGNORE_ROW_ON_DUPKEY_INDEX
RETRY_ON_ROW_CHANGE
...
Рейтинг: 0 / 0
Сравнение механизмов хинтования.
    #37855618
Фотография AmKad
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
AmKad,

Правда первый работает с некоторыми недокументированными ограничениями. CHANGE_DUPKEY_ERROR_INDEX. Update
...
Рейтинг: 0 / 0
Сравнение механизмов хинтования.
    #37855632
Фотография Ggg_old
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Проталкивание предикатов и вышеназванные опции влияющие на логику выполнения не отностяся к хинтам оптимизатора, а скорее являются свойством навороченности оптимизмтора вообще (проталкивание предиктов) и возможностей ядра субд. Мне бы хотелось в этом топике сконцентрироваться только на инструментах хинтования.
Я еще слышал, что в оракле админ может навзятать план выполнения запроса, не трогая его текст.
...
Рейтинг: 0 / 0
Сравнение механизмов хинтования.
    #37855649
Фотография AmKad
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Ggg_oldПроталкивание предикатов и вышеназванные опции влияющие на логику выполнения не отностяся к хинтам оптимизатораДа ладно? Разве это
PUSH_PRED
NO_PUSH_PRED
RESULT_CACHE
NO_RESULT_CACHE
DYNAMIC_SAMPLING
CACHE
MONITOR
NO_XML_QUERY_REWRITE
и то что я привел выше, не хинты?
...
Рейтинг: 0 / 0
Сравнение механизмов хинтования.
    #37855682
Ggg_oldЯ еще слышал, что в оракле админ может навзятать план выполнения запроса, не трогая его текст.
А указать тип соединения таблиц это навязать план? Если да, то в оракле это можно. Вопрос остается в том обязательно ли оракл будет выполнять этот хинт, т.е. является ли он директивным.
Если имеется ввиду указать непосредственно весь план выполнения запроса, то в ORACLE и MSSQL нельзя, но можно в Firebird.
...
Рейтинг: 0 / 0
Сравнение механизмов хинтования.
    #37855694
Фотография Ggg_old
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
2AmCad: После изучения док про хинты push_pred, cache и прочее - согласен, это хинты оптимизатора, влияющие на стратегию.
Просто в SA протокалкивание предиката это часть возможности оптимизмтора и не хинтуется.
А вот CHANGE_DUPKEY_ERROR_INDEX, IGNORE_ROW_ON_DUPKEY_INDEX, RETRY_ON_ROW_CHANGE все-таки параметры скорее ядра а не оптимизмтора.
...
Рейтинг: 0 / 0
Сравнение механизмов хинтования.
    #37855698
Фотография Ggg_old
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
а вообще список хинтов оптимизатора оракла впечатляет:
http://docs.oracle.com/cd/E11882_01/server.112/e26088/sql_elements006.htm#autoId3
...
Рейтинг: 0 / 0
Сравнение механизмов хинтования.
    #37855701
Фотография AmKad
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Ggg_oldА вот CHANGE_DUPKEY_ERROR_INDEX, IGNORE_ROW_ON_DUPKEY_INDEX, RETRY_ON_ROW_CHANGE все-таки параметры скорее ядра а не оптимизмтора.Согласно доке, это все-таки хинты. Но если Вы не согласны, я не хочу об этом спорить. Чем они отличаются от остальных - я уже написал. А понятие ядро - для меня несколько абстрактно.
...
Рейтинг: 0 / 0
Сравнение механизмов хинтования.
    #37855714
Фотография Apex
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Ggg_old2AmCad: После изучения док про хинты push_pred, cache и прочее - согласен, это хинты оптимизатора, влияющие на стратегию.
Просто в SA протокалкивание предиката это часть возможности оптимизмтора и не хинтуется.
А вот CHANGE_DUPKEY_ERROR_INDEX, IGNORE_ROW_ON_DUPKEY_INDEX, RETRY_ON_ROW_CHANGE все-таки параметры скорее ядра а не оптимизмтора.
В Оракле это тоже возможность оптимизатора. Вообще, почти все, что можно сделать хинтом, Оракловый оптимизатор способен сделать самостоятельно. Хинты вроде как задумывались на крайний случай.

Ggg_oldа вообще список хинтов оптимизатора оракла впечатляет
Это потому, что нет ни одного серьезного приложения, которое бы обходилось без хинтов, оракловый оптимизатор, как впрочем и сам оракл, очень богат на баги, хинты в оракле - суровая необходимость.
...
Рейтинг: 0 / 0
Сравнение механизмов хинтования.
    #37855722
servit
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Ggg_oldВ качестве собственной ликвидации безграмотности и расширения кругозора хотелось бы узнать в каких рсубд какие есть возможности хинтования. Например: хинтовать нельзя вообще, можно указывать только индексы, можно хинтовать еще план выполнения (стратегию соединений итп.).
Если можно, то вкратце хотелось бы что-бы каждый поделился возможностяим по своей субд, с которой работает.Жаль, что Вы сузили круг допущенных к рассмотрению типов СУБД лишь реляционными.

Хотя в других - не РСУБД - тоже есть хинты, например:

Query Optimization Options

ExtentSize and Selectivity
...
Рейтинг: 0 / 0
Сравнение механизмов хинтования.
    #37855728
Фотография Ggg_old
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
2servit: да, интерисует именно рсубд, как реализующие идею декларативного программирования и имеющие массовое распространение. Да и сравнивать их между собой имеет смысл, а вот с каше как бы нет, т.к. продукты разные.
...
Рейтинг: 0 / 0
Сравнение механизмов хинтования.
    #37855733
Favn
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Ggg_oldНасколько я слышал, что у DB2 прямых хинтов нет, т.к. считается что оптимизатор шибко умный, но ямогу ошибаться либо мои знания устарели.Ну, скажем так, есть, но не хинты :)
В самих запросах хинты не указываются. Обычно, если что-то не так, разбираются почему и, например, меняют уровень оптимизации, от которого зависит "вдумчивость" работы оптимизатора.
Если все совсем плохо, можно написать optimization profile , который "рекомендует" желаемый план выполнения, не меняя самих запросов/программ. Но это - "последний довод", обычно достаточно разобраться ( db2advise , например), почему план оптимизатора плохой.
А так да, действительно "шибко умный", я этими хинтами ни разу не пользовался.
...
Рейтинг: 0 / 0
Сравнение механизмов хинтования.
    #37855763
Фотография Ggg_old
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
а подскажет кто-то ссылочку на аналогичный ДБ2-шному механизму указания плана из-вне у оракла?
...
Рейтинг: 0 / 0
Сравнение механизмов хинтования.
    #37855812
Yo.!
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Ggg_oldа подскажет кто-то ссылочку на аналогичный ДБ2-шному механизму указания плана из-вне у оракла?

механизм заветься stored outlines
вкратце о нем тут: http://www.oracle.com/technetwork/database/bi-datawarehousing/twp-sql-plan-management-11gr2-133099.pdf
...
Рейтинг: 0 / 0
Сравнение механизмов хинтования.
    #37856060
pkarklin
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Ну, что ж, начнем..

Код: sql
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
33.
34.
35.
36.
37.
38.
39.
40.
41.
42.
43.
44.
45.
WITH ( <table_hint> [ [ , ]...n ] )

<table_hint> ::= 
[ NOEXPAND ] { 
    INDEX ( index_value [ ,...n ] ) | INDEX = ( index_value )
  | FASTFIRSTROW 
  | FORCESEEK
  | HOLDLOCK 
  | NOLOCK 
  | NOWAIT
  | PAGLOCK 
  | READCOMMITTED 
  | READCOMMITTEDLOCK 
  | READPAST 
  | READUNCOMMITTED 
  | REPEATABLEREAD 
  | ROWLOCK 
  | SERIALIZABLE 
  | TABLOCK 
  | TABLOCKX 
  | UPDLOCK 
  | XLOCK 
} 

<table_hint_limited> ::=
{
    KEEPIDENTITY 
  | KEEPDEFAULTS 
  | FASTFIRSTROW 
  | HOLDLOCK 
  | IGNORE_CONSTRAINTS 
  | IGNORE_TRIGGERS 
  | NOWAIT
  | PAGLOCK 
  | READCOMMITTED 
  | READCOMMITTEDLOCK 
  | READPAST 
  | REPEATABLEREAD 
  | ROWLOCK 
  | SERIALIZABLE 
  | TABLOCK 
  | TABLOCKX 
  | UPDLOCK 
  | XLOCK 
} 
...
Рейтинг: 0 / 0
Сравнение механизмов хинтования.
    #37856064
pkarklin
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Код: sql
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
<query_hint > ::= 
{ { HASH | ORDER } GROUP 
  | { CONCAT | HASH | MERGE } UNION 
  | { LOOP | MERGE | HASH } JOIN 
  | EXPAND VIEWS 
  | FAST number_rows 
  | FORCE ORDER 
  | IGNORE_NONCLUSTERED_COLUMNSTORE_INDEX
  | KEEP PLAN 
  | KEEPFIXED PLAN
  | MAXDOP number_of_processors 
  | MAXRECURSION number 
  | OPTIMIZE FOR ( @variable_name { UNKNOWN | = literal_constant } [ , ...n ] )
  | OPTIMIZE FOR UNKNOWN
  | PARAMETERIZATION { SIMPLE | FORCED }
  | RECOMPILE
  | ROBUST PLAN 
  | USE PLAN N'xml_plan'
...
Рейтинг: 0 / 0
Сравнение механизмов хинтования.
    #37856066
pkarklin
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Plan Guides

Собственно:
Код: sql
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
sp_create_plan_guide 
@name = N'Guide1',
@stmt = N'SELECT *FROM Sales.SalesOrderHeader AS h,
        Sales.Customer AS c,
        Sales.SalesTerritory AS t
        WHERE h.CustomerID = c.CustomerID 
            AND c.TerritoryID = t.TerritoryID
            AND CountryRegionCode = @Country_region',
@type = N'OBJECT',
@module_or_batch = N'Sales.GetSalesOrderByCountry',
@params = NULL,
@hints = N'OPTION (OPTIMIZE FOR (@Country_region = N''US''))';
...
Рейтинг: 0 / 0
Сравнение механизмов хинтования.
    #37856069
pkarklin
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Код: sql
1.
2.
3.
4.
SELECT * FROM AdventureWorks2012.Sales.SalesOrderHeader AS h
INNER JOIN AdventureWorks2012.Sales.SalesOrderDetail AS d 
    ON h.SalesOrderID = d.SalesOrderID
WHERE h.SalesOrderID = 45639;




Код: sql
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
sp_create_plan_guide 
    @name = N'TemplateGuide1',
    @stmt = N'SELECT * FROM AdventureWorks2012.Sales.SalesOrderHeader AS h
              INNER JOIN AdventureWorks2012.Sales.SalesOrderDetail AS d 
                  ON h.SalesOrderID = d.SalesOrderID
              WHERE h.SalesOrderID = @0',
    @type = N'TEMPLATE',
    @module_or_batch = NULL,
    @params = N'@0 int',
    @hints = N'OPTION(PARAMETERIZATION FORCED)';



Код: sql
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
DECLARE @stmt nvarchar(max);
DECLARE @params nvarchar(max);
EXEC sp_get_query_template 
    N'SELECT * FROM AdventureWorks2012.Sales.SalesOrderHeader AS h
      INNER JOIN AdventureWorks2012.Sales.SalesOrderDetail AS d 
          ON h.SalesOrderID = d.SalesOrderID
      WHERE h.SalesOrderID = 45639;',
    @stmt OUTPUT, 
    @params OUTPUT
EXEC sp_create_plan_guide N'TemplateGuide1', 
    @stmt, 
    N'TEMPLATE', 
    NULL, 
    @params, 
    N'OPTION(PARAMETERIZATION FORCED)';
...
Рейтинг: 0 / 0
Сравнение механизмов хинтования.
    #37856070
pkarklin
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Код: sql
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
33.
34.
35.
--Create a procedure on which to define the plan guide.
IF OBJECT_ID(N'Sales.GetSalesOrderByCountry', N'P') IS NOT NULL
    DROP PROCEDURE Sales.GetSalesOrderByCountry;
GO
CREATE PROCEDURE Sales.GetSalesOrderByCountry 
    (@Country nvarchar(60))
AS
BEGIN
    SELECT *
    FROM Sales.SalesOrderHeader AS h 
    INNER JOIN Sales.Customer AS c ON h.CustomerID = c.CustomerID
    INNER JOIN Sales.SalesTerritory AS t ON c.TerritoryID = t.TerritoryID
    WHERE t.CountryRegionCode = @Country;
END
GO
--Create the plan guide.
EXEC sp_create_plan_guide N'Guide3',
    N'SELECT *
    FROM Sales.SalesOrderHeader AS h 
    INNER JOIN Sales.Customer AS c ON h.CustomerID = c.CustomerID
    INNER JOIN Sales.SalesTerritory AS t ON c.TerritoryID = t.TerritoryID
    WHERE t.CountryRegionCode = @Country',
    N'OBJECT',
    N'Sales.GetSalesOrderByCountry',
    NULL,
    N'OPTION (OPTIMIZE FOR (@Country = N''US''))';
GO
--Disable the plan guide.
EXEC sp_control_plan_guide N'DISABLE', N'Guide3';
GO
--Enable the plan guide.
EXEC sp_control_plan_guide N'ENABLE', N'Guide3';
GO
--Drop the plan guide.
EXEC sp_control_plan_guide N'DROP', N'Guide3';
...
Рейтинг: 0 / 0
Сравнение механизмов хинтования.
    #37856578
Фотография Ggg_old
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Ага пока выходит такая картина, если есть замечания, дпололняйте:
Код: plaintext
1.
2.
3.
4.
5.
6.
ORACLE...: индекс(+), стратегия соединения(+), внешний план(+), Метахинты: [статистика(?), параллельность(+), допхинты(см.ссылку) ]
DB2:.....: индекс(-), стратегии соединения(-), внешний план(+), Метахинты: [статистика(?), параллельность(?), допхинты(уровень глубины оптимизации) ]
SybaseSA.: индекс(+), стратегия соединения(-), внешний план(-), Метахинты: [статистика(+), параллельность(+), допхинты(тип нагрузки запроса, уровень глубины оптимизации) ]
MSSQL....: индекс(+), стратегия соединения(+), внешний план(+), Метахинты: [статистика(?), параллельность(?), допхинты(?) ]
Firebird.: индекс(-), стратегия соединения(-), внешний план(+), Метахинты: [?]

...
Рейтинг: 0 / 0
Сравнение механизмов хинтования.
    #37856603
Фотография Ggg_old
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Под метахинтами понимаются хинты, которые не указывают оптимизатору напрямую что именно делать, а декларативно описывают некие свойства запроса, на основании которых оптимизатор может выбирать стратегию своей работы. Пример: уровень параллельности запроса, уровень "заумности" оптимизатора на конкретном запросе, хинты кардинальности значения в колонке итп.
...
Рейтинг: 0 / 0
Сравнение механизмов хинтования.
    #37856618
pkarklin
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Ggg_oldпараллельность(?)

Почему знак вопроса?

Код: sql
1.
MAXDOP number_of_processors 



Ggg_old[статистика(?)

Покрывается этим:
Код: sql
1.
2.
  | OPTIMIZE FOR ( @variable_name { UNKNOWN | = literal_constant } [ , ...n ] )
  | OPTIMIZE FOR UNKNOWN



Ggg_oldдопхинты(тип нагрузки запроса, уровень глубины оптимизации)

А можно на примерах показать планы запросов при таких хинтах и без оных?
...
Рейтинг: 0 / 0
Сравнение механизмов хинтования.
    #37856629
Фотография softwarer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Ggg_oldУ оракла вроде как богатые возможности, но деталей и возможностей не знаю совсем.
У Оракла есть фича, называемая stored outlines - возможность зафиксировать план запроса. То есть потребовать, чтобы некий запрос всегда-всегда-всегда выполнялся именно по тому плану, который построен для него сейчас. Технически эта фича реализована через хинты - то есть для запроса сохраняется в базе набор хинтов, фиксирующих план. Думаю, это даёт представление о соотношении "умений оптимизатора вообще" и "возможностей хинтами этим управлять".
...
Рейтинг: 0 / 0
Сравнение механизмов хинтования.
    #37856645
pkarklin
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
В MS SQL можно даже так:

Код: sql
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
33.
34.
35.
36.
37.
38.
39.
40.
41.
42.
43.
44.
45.
46.
47.
48.
49.
50.
51.
52.
53.
54.
55.
56.
57.
58.
59.
60.
61.
62.
63.
64.
65.
66.
67.
68.
69.
70.
71.
72.
73.
74.
75.
76.
77.
78.
79.
80.
81.
82.
83.
84.
85.
86.
87.
88.
89.
90.
91.
92.
93.
94.
95.
96.
97.
98.
99.
100.
101.
102.
103.
104.
105.
106.
107.
108.
109.
110.
111.
112.
113.
114.
115.
116.
USE tempdb;
GO
CREATE TABLE t1(i INT)
CREATE TABLE t2(j INT)
GO
SELECT * FROM t1, t2 WHERE t1.i = t2.j OPTION (USE PLAN N'
<ShowPlanXML xmlns="http://schemas.microsoft.com/sqlserver/2004/07/showplan" Version="0.5" Build="9.00.938">
  <BatchSequence>
    <Batch>
      <Statements>
        <StmtSimple StatementText="SELECT * FROM t1, t2 WHERE t1.i = t2.j" StatementId="1" 
         StatementCompId="1" StatementType="SELECT" StatementSubTreeCost="0.0514796" 
         StatementEstRows="1" StatementOptmLevel="FULL">
          <StatementSetOptions QUOTED_IDENTIFIER="true" ARITHABORT="true" CONCAT_NULL_YIELDS_NULL="true" 
           ANSI_NULLS="true" ANSI_PADDING="true" ANSI_WARNINGS="true" NUMERIC_ROUNDABORT="false" />
          <QueryPlan CachedPlanSize="20">
            <RelOp NodeId="0" PhysicalOp="Merge Join" LogicalOp="Inner Join" EstimateRows="1" 
             EstimateIO="0.000313" EstimateCPU="0.00564738" AvgRowSize="15" 
             EstimatedTotalSubtreeCost="0.0514796" Parallel="0" EstimateRebinds="0" EstimateRewinds="0">
              <OutputList>
                <ColumnReference Database="[tempdb]" Schema="[dbo]" Table="[t1]" Column="i" />
                <ColumnReference Database="[tempdb]" Schema="[dbo]" Table="[t2]" Column="j" />
              </OutputList>
              <Merge ManyToMany="1">
                <InnerSideJoinColumns>
                  <ColumnReference Database="[tempdb]" Schema="[dbo]" Table="[t2]" Column="j" />
                </InnerSideJoinColumns>
                <OuterSideJoinColumns>
                  <ColumnReference Database="[tempdb]" Schema="[dbo]" Table="[t1]" Column="i" />
                </OuterSideJoinColumns>
                <Residual>
                  <ScalarOperator ScalarString="[tempdb].[dbo].[t2].[j]=[tempdb].[dbo].[t1].[i]">
                    <Compare CompareOp="EQ">
                      <ScalarOperator>
                        <Identifier>
                          <ColumnReference Database="[tempdb]" Schema="[dbo]" Table="[t2]" Column="j" />
                        </Identifier>
                      </ScalarOperator>
                      <ScalarOperator>
                        <Identifier>
                          <ColumnReference Database="[tempdb]" Schema="[dbo]" Table="[t1]" Column="i" />
                        </Identifier>
                      </ScalarOperator>
                    </Compare>
                  </ScalarOperator>
                </Residual>
                <RelOp NodeId="1" PhysicalOp="Sort" LogicalOp="Sort" EstimateRows="1" EstimateIO="0.01625" 
                 EstimateCPU="0.000100011" AvgRowSize="11" EstimatedTotalSubtreeCost="0.0227581" Parallel="0" 
                 EstimateRebinds="0" EstimateRewinds="0">
                  <OutputList>
                    <ColumnReference Database="[tempdb]" Schema="[dbo]" Table="[t1]" Column="i" />
                  </OutputList>
                  <MemoryFractions Input="1" Output="0.5" />
                  <Sort Distinct="0">
                    <OrderBy>
                      <OrderByColumn Ascending="1">
                        <ColumnReference Database="[tempdb]" Schema="[dbo]" Table="[t1]" Column="i" />
                      </OrderByColumn>
                    </OrderBy>
                    <RelOp NodeId="2" PhysicalOp="Table Scan" LogicalOp="Table Scan" EstimateRows="1"
                     EstimateIO="0.0063285" EstimateCPU="7.96e-005" AvgRowSize="11" 
                     EstimatedTotalSubtreeCost="0.0064081" Parallel="0" EstimateRebinds="0" 
                     EstimateRewinds="0">
                      <OutputList>
                        <ColumnReference Database="[tempdb]" Schema="[dbo]" Table="[t1]" Column="i" />
                      </OutputList>
                      <TableScan Ordered="0" ForcedIndex="0">
                        <DefinedValues>
                          <DefinedValue>
                            <ColumnReference Database="[tempdb]" Schema="[dbo]" Table="[t1]" Column="i" />
                          </DefinedValue>
                        </DefinedValues>
                        <Object Database="[tempdb]" Schema="[dbo]" Table="[t1]" />
                      </TableScan>
                    </RelOp>
                  </Sort>
                </RelOp>
                <RelOp NodeId="3" PhysicalOp="Sort" LogicalOp="Sort" EstimateRows="1" 
                 EstimateIO="0.01625" EstimateCPU="0.000100011" AvgRowSize="11" 
                 EstimatedTotalSubtreeCost="0.0227581" Parallel="0" EstimateRebinds="0" EstimateRewinds="0">
                  <OutputList>
                    <ColumnReference Database="[tempdb]" Schema="[dbo]" Table="[t2]" Column="j" />
                  </OutputList>
                  <MemoryFractions Input="0.5" Output="0.5" />
                  <Sort Distinct="0">
                    <OrderBy>
                      <OrderByColumn Ascending="1">
                        <ColumnReference Database="[tempdb]" Schema="[dbo]" Table="[t2]" Column="j" />
                      </OrderByColumn>
                    </OrderBy>
                    <RelOp NodeId="4" PhysicalOp="Table Scan" LogicalOp="Table Scan" EstimateRows="1" 
                     EstimateIO="0.0063285" EstimateCPU="7.96e-005" AvgRowSize="11" 
                     EstimatedTotalSubtreeCost="0.0064081" Parallel="0" EstimateRebinds="0" 
                     EstimateRewinds="0">
                      <OutputList>
                        <ColumnReference Database="[tempdb]" Schema="[dbo]" Table="[t2]" Column="j" />
                      </OutputList>
                      <TableScan Ordered="0" ForcedIndex="0">
                        <DefinedValues>
                          <DefinedValue>
                            <ColumnReference Database="[tempdb]" Schema="[dbo]" Table="[t2]" Column="j" />
                          </DefinedValue>
                        </DefinedValues>
                        <Object Database="[tempdb]" Schema="[dbo]" Table="[t2]" />
                      </TableScan>
                    </RelOp>
                  </Sort>
                </RelOp>
              </Merge>
            </RelOp>
          </QueryPlan>
        </StmtSimple>
      </Statements>
    </Batch>
  </BatchSequence>
</ShowPlanXML>')
...
Рейтинг: 0 / 0
Сравнение механизмов хинтования.
    #37856902
Фотография Ggg_old
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
pkarklin: мне кажется,чт аналог этих опций есть в мсскл, дам вам только выдержку из док:
У SqlAnywhere как на уровне всей базы так и на уровне конкретного запроса в числе хинтов есть такие опции как:
optimization_workload option
http://infocenter.sybase.com/help/index.jsp?docset=/com.sybase.help.sqlanywhere.12.0.1/sqlanywhere_en12/help_top_index.htm&docSetID=1744
Determines whether query processing is optimized towards a workload that is a mix of updates and reads or a workload that is predominantly read-based.
The optimization_workload option controls whether SQL Anywhere optimizes queries for a workload that is a mix of updates and reads or predominantly read only.

If the option is set to Mixed (the default), SQL Anywhere chooses query optimization algorithms appropriate for a workload that is a mixture of short inserts, updates, and deletes and longer running read-only queries.

If the option is set to OLAP , SQL Anywhere chooses algorithms appropriate for a workload that consists for the most part of long-running queries, combined with batch updates. In particular, the optimizer may choose to use the Clustered Hash Group By query execution algorithm.

When the option is set to OLAP, the Clustered Hash Group By algorithm is enabled. If the option is set to Mixed (the default), it is disabled.


optimization_level option
Controls the amount of effort made by the SQL Anywhere query optimizer to find an access plan for a SQL statement.

optimization_goal option
Determines whether query processing is optimized towards returning the first row quickly, or minimizing the cost of returning the complete result set.
The optimization_goal option controls whether SQL Anywhere optimizes SQL data manipulation language (DML) statements for response time or total resource consumption.

If the option is set to All-rows (the default) , then SQL Anywhere optimizes a query to choose an access plan with the minimal estimated total retrieval time. Setting optimization_goal to All-rows may be appropriate for applications that intend to process the entire result set, such as Sybase PowerBuilder DataWindow applications. A setting of All-rows is also appropriate for insensitive (ODBC static) cursors since the entire result is materialized when the cursor is opened. It may also be appropriate for scroll (ODBC keyset-driven) cursors, since the intent of such a cursor is to permit scrolling through the result set.

If the option is set to First-row , SQL Anywhere chooses an access plan that is intended to reduce the time to fetch the first row of the query's result, possibly at the expense of total retrieval time. In particular, the SQL Anywhere optimizer will typically avoid, if possible, access plans that require the materialization of results to reduce the time to return the first row . With this setting, the optimizer favors access plans that utilize an index to satisfy a query's ORDER BY clause, rather than plans that require an explicit sorting operation.
...
Рейтинг: 0 / 0
Сравнение механизмов хинтования.
    #37856908
Фотография Ggg_old
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
С учетом замечаний таблица выходит такая:
Код: plaintext
1.
2.
3.
4.
5.
ORACLE...: индекс(+), стратегия соединения(+), внешний план(+), Метахинты: [статистика(?), параллельность(+), допхинты(см.ссылку) ]
DB2:.....: индекс(-), стратегии соединения(-), внешний план(+), Метахинты: [статистика(?), параллельность(?), допхинты(уровень глубины оптимизации) ]
SybaseSA.: индекс(+), стратегия соединения(-), внешний план(-), Метахинты: [статистика(+), параллельность(+), допхинты(тип нагрузки запроса, уровень глубины оптимизации) ]
MSSQL....: индекс(+), стратегия соединения(+), внешний план(+), Метахинты: [статистика(+), параллельность(+), допхинты(?) ]
Firebird.: индекс(-), стратегия соединения(-), внешний план(+), Метахинты: [?]
...
Рейтинг: 0 / 0
Сравнение механизмов хинтования.
    #37856912
Фотография Ggg_old
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
знаком ? я указываю, что не знаю есть или нет и как оно делается, т.е. эта опция в таблице требует уточнения.
...
Рейтинг: 0 / 0
Сравнение механизмов хинтования.
    #37856921
pkarklin
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Ggg_old,

Я бы добавил в список хинты блокировок (Locking Hints), как отдельный класс. Довольно часто применемая фича в OLTP.
...
Рейтинг: 0 / 0
Сравнение механизмов хинтования.
    #37857067
pkarklin
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Ggg_old,

авторoptimization_workload option

Прямого аналога нет. Из имеющихся серверных опций:

optimize for ad hoc workloads

BOLThe optimize for ad hoc workloads option is used to improve the efficiency of the plan cache for workloads that contain many single use ad hoc batches. When this option is set to 1, the Database Engine stores a small compiled plan stub in the plan cache when a batch is compiled for the first time, instead of the full compiled plan. This helps to relieve memory pressure by not allowing the plan cache to become filled with compiled plans that are not reused.

The compiled plan stub allows the Database Engine to recognize that this ad hoc batch has been compiled before but has only stored a compiled plan stub, so when this batch is invoked (compiled or executed) again, the Database Engine compiles the batch, removes the compiled plan stub from the plan cache, and adds the full compiled plan to the plan cache.

авторoptimization_level option

Есть Trace Flag 2301

MSDNTrace flag 2301 enables advanced optimizations that are specific to decision support queries. This option applies to decision support processing of large data sets.


авторoptimization_goal option

Код: sql
1.
FAST number_rows



BOLSpecifies that the query is optimized for fast retrieval of the first number_rows. This is a nonnegative integer. After the first number_rows are returned, the query continues execution and produces its full result set.
...
Рейтинг: 0 / 0
Сравнение механизмов хинтования.
    #37857265
А есть спецы по PostgreSQL, как там обстоят с этим дела?
...
Рейтинг: 0 / 0
Сравнение механизмов хинтования.
    #37857321
Фотография Ggg_old
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Рассмтарвиаем только хинты, влияющие на план запроса. Хинты уровня изоляции транзакций, управления кэшами, кэшированием планов, и т.п. не входят в рассмотрение. Т.е. интересно только то, как SQL превращается в алгоритмы.

Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
ORACLE...: индекс(+), стратегия соединения(+), внешний план(+), Метахинты: [статистика(?), параллельность(+), допхинты(см.ссылку) ]
DB2:.....: индекс(-), стратегии соединения(-), внешний план(+), Метахинты: [статистика(?), параллельность(?), допхинты(уровень глубины оптимизации) ]
SybaseSA.: индекс(+), стратегия соединения(-), внешний план(-), Метахинты: [статистика(+), параллельность(+), допхинты(тип нагрузки запроса, уровень глубины оптимизацииб оптимизация получения набора данных) ]
SybaseASE: индекс(+), стратегия соединения(?), внешний план(?), Метахинты: [(?) ]
MSSQL....: индекс(+), стратегия соединения(+), внешний план(+), Метахинты: [статистика(+), параллельность(+), допхинты(уровень оптимизации, оптимизация получения набора данных) ]
Firebird.: индекс(-), стратегия соединения(-), внешний план(+), Метахинты: [?]
Postgres.: индекс(?), стратегия соединения(?), внешний план(?), Метахинты: [(?) ]
Informix.: индекс(?), стратегия соединения(?), внешний план(?), Метахинты: [(?) ]
...
Рейтинг: 0 / 0
Сравнение механизмов хинтования.
    #37857424
pkarklin
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Ggg_old,

Ок.
...
Рейтинг: 0 / 0
Сравнение механизмов хинтования.
    #37858720
ad hoc
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
pkarklin optimize for ad hoc workloads

BOLThe optimize for ad hoc workloads option is used to improve the efficiency of the plan cache for workloads that contain many single use ad hoc batches. When this option is set to 1, the Database Engine stores a small compiled plan stub in the plan cache when a batch is compiled for the first time, instead of the full compiled plan. This helps to relieve memory pressure by not allowing the plan cache to become filled with compiled plans that are not reused.

The compiled plan stub allows the Database Engine to recognize that this ad hoc batch has been compiled before but has only stored a compiled plan stub, so when this batch is invoked (compiled or executed) again, the Database Engine compiles the batch, removes the compiled plan stub from the plan cache, and adds the full compiled plan to the plan cache.

Что-то не совсем понятно написано. Т.е. optimize for ad hoc workloads нужно для минимизации: кэширования планов таких запросов, кэширования резалтсета, кэширования страниц базы.
А оптимизатору время на оптимизацию плана запроса выделяется больше при включении этой опции?
...
Рейтинг: 0 / 0
Сравнение механизмов хинтования.
    #37858877
pkarklin
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ad hoc,

Опция меняет механику генерации плана. Время не меняется.
...
Рейтинг: 0 / 0
Сравнение механизмов хинтования.
    #37858936
А вот как обстоят дела с PostgreSQL.
А в PostgreSQL что можно хинтовать?
Почему не нужно хинтование
Как считаете оно действительно не нужно?
...
Рейтинг: 0 / 0
Сравнение механизмов хинтования.
    #37860122
Ivan Durak
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
FavnGgg_oldНасколько я слышал, что у DB2 прямых хинтов нет, т.к. считается что оптимизатор шибко умный, но ямогу ошибаться либо мои знания устарели.Ну, скажем так, есть, но не хинты :)
В самих запросах хинты не указываются. Обычно, если что-то не так, разбираются почему и, например, меняют уровень оптимизации, от которого зависит "вдумчивость" работы оптимизатора.
Да это практически везде так!! И в МССКЛ и даже в Оракле. Хорошо собранная статистика заменяет тонны лишних хинтов.
...
Рейтинг: 0 / 0
Сравнение механизмов хинтования.
    #37861898
MySQL хинты
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Ggg_oldРассмтарвиаем только хинты, влияющие на план запроса. Хинты уровня изоляции транзакций, управления кэшами, кэшированием планов, и т.п. не входят в рассмотрение. Т.е. интересно только то, как SQL превращается в алгоритмы.

Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
ORACLE...: индекс(+), стратегия соединения(+), внешний план(+), Метахинты: [статистика(?), параллельность(+), допхинты(см.ссылку) ]
DB2:.....: индекс(-), стратегии соединения(-), внешний план(+), Метахинты: [статистика(?), параллельность(?), допхинты(уровень глубины оптимизации) ]
SybaseSA.: индекс(+), стратегия соединения(-), внешний план(-), Метахинты: [статистика(+), параллельность(+), допхинты(тип нагрузки запроса, уровень глубины оптимизацииб оптимизация получения набора данных) ]
SybaseASE: индекс(+), стратегия соединения(?), внешний план(?), Метахинты: [(?) ]
MSSQL....: индекс(+), стратегия соединения(+), внешний план(+), Метахинты: [статистика(+), параллельность(+), допхинты(уровень оптимизации, оптимизация получения набора данных) ]
Firebird.: индекс(-), стратегия соединения(-), внешний план(+), Метахинты: [?]
Postgres.:  индекс(+-) , стратегия соединения(?), внешний план(?), Метахинты: [(?) ]
Informix.: индекс(?), стратегия соединения(?), внешний план(?), Метахинты: [(?) ]

Для PostgreSQL есть внешний плагин разработанный Олегом Бартуновым для отключения индексов, так что отчасти есть.

А в MySQL есть хинты и что они могут?
...
Рейтинг: 0 / 0
Сравнение механизмов хинтования.
    #37862003
MySQL хинты
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
ORACLE...: индекс(+), стратегия соединения(+), внешний план(+), Метахинты: [статистика(?), параллельность(+), допхинты(см.ссылку) ]
DB2:.....: индекс(-), стратегии соединения(-), внешний план(+), Метахинты: [статистика(?), параллельность(?), допхинты(уровень глубины оптимизации) ]
SybaseSA.: индекс(+), стратегия соединения(-), внешний план(-), Метахинты: [статистика(+), параллельность(+), допхинты(тип нагрузки запроса, уровень глубины оптимизацииб оптимизация получения набора данных) ]
SybaseASE: индекс(+), стратегия соединения(?), внешний план(?), Метахинты: [(?) ]
MSSQL....: индекс(+), стратегия соединения(+), внешний план(+), Метахинты: [статистика(+), параллельность(+), допхинты(уровень оптимизации, оптимизация получения набора данных) ]
Firebird.: индекс(-), стратегия соединения(-), внешний план(+), Метахинты: [?]
Postgres.:  индекс(+-) , стратегия соединения(-), внешний план(-), Метахинты: [(-) ]
MySQL.:  индекс(+) , стратегия соединения(-), внешний план(-), Метахинты: [(-) ]
Informix.: индекс(?), стратегия соединения(?), внешний план(?), Метахинты: [(?) ]
В MySQL возможны только хинтование индексов USE/IGNORE INDEX и порядок соединения таблиц вместо JOIN пишем STRAIGHT_JOIN. Выбора стратегий соединения быть не может, т.к. там всего только одна стратегия NLJ :)
А в MySQL что можно хинтовать?
...
Рейтинг: 0 / 0
Сравнение механизмов хинтования.
    #37862005
хинты
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
ORACLE...: индекс(+), стратегия соединения(+), внешний план(+), Метахинты: [статистика(?), параллельность(+), допхинты(см.ссылку) ]
MSSQL....: индекс(+), стратегия соединения(+), внешний план(+), Метахинты: [статистика(+), параллельность(+), допхинты(уровень оптимизации, оптимизация получения набора данных) ]
SybaseSA.: индекс(+), стратегия соединения(-), внешний план(-), Метахинты: [статистика(+), параллельность(+), допхинты(тип нагрузки запроса, уровень глубины оптимизацииб оптимизация получения набора данных) ]
SybaseASE: индекс(+), стратегия соединения(?), внешний план(?), Метахинты: [(?) ]
DB2:.....: индекс(-), стратегии соединения(-), внешний план(+), Метахинты: [статистика(?), параллельность(?), допхинты(уровень глубины оптимизации) ]
Firebird.: индекс(-), стратегия соединения(-), внешний план(+), Метахинты: [?]
Postgres.:  индекс(+-) , стратегия соединения(-), внешний план(-), Метахинты: [(-) ]
MySQL....:  индекс(+) , стратегия соединения(-), внешний план(-), Метахинты: [(-) ]
Informix.: индекс(?), стратегия соединения(?), внешний план(?), Метахинты: [(?) ]
...
Рейтинг: 0 / 0
Сравнение механизмов хинтования.
    #37862897
Favn
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Ggg_old интересно только то, как SQL превращается в алгоритмы.
Код: plaintext
1.
DB2:.....: индекс(-), стратегии соединения(-), внешний план(+), Метахинты: [статистика(?), параллельность(?), допхинты(уровень глубины оптимизации) ]
Раз пошла такая пьянка, прочел-таки документацию :)
Индексы - да, стратегии соединения - да, план - да . С планом все сложнее, потому что DB2 - компилятор, и план всегда генерится и сохраняется как результат компиляции запроса. При желании его можно фиксировать и не пересоздавать в будущем и без хинтов.
Кстати, о превращении в алгоритмы - есть возможность настроить и поведение фазы переформулирования запроса оптимизатором .
Можно в профиле хинта установить значения переменных компилятора SQL , управляющих его поведением.
Можно указать до запроса, какой профиль хинтов сейчас надо использовать .
Использование статистики, не соответствующей текущей (скажем, выгрузка-загрузка статистики из другой БД, или фиксация плана на другой момент времени) возможно, но другими механизмами.
...
Рейтинг: 0 / 0
Сравнение механизмов хинтования.
    #37865719
Фотография Ggg_old
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
ORACLE...: индекс(+), стратегия соединения(+), внешний план(+), Метахинты: [статистика(?), параллельность(+), допхинты(см.ссылку) ]
MSSQL....: индекс(+), стратегия соединения(+), внешний план(+), Метахинты: [статистика(+), параллельность(+), допхинты(уровень оптимизации, оптимизация получения набора данных) ]
SybaseSA.: индекс(+), стратегия соединения(-), внешний план(-), Метахинты: [статистика(+), параллельность(+), допхинты(тип нагрузки запроса, уровень глубины оптимизацииб оптимизация получения набора данных) ]
SybaseASE: индекс(+), стратегия соединения(?), внешний план(?), Метахинты: [(?) ]
DB2:.....: индекс(+), стратегии соединения(+), внешний план(+), Метахинты: [статистика(?), параллельность(?), допхинты(уровень глубины оптимизации) ]
Firebird.: индекс(-), стратегия соединения(-), внешний план(+), Метахинты: [?]
Postgres.: индекс(+-), стратегия соединения(-), внешний план(-), Метахинты: [(-) ]
MySQL....: индекс(+), стратегия соединения(-), внешний план(-), Метахинты: [(-) ]
Informix.: индекс(?), стратегия соединения(?), внешний план(?), Метахинты: [(?) ]
...
Рейтинг: 0 / 0
Сравнение механизмов хинтования.
    #37865721
Фотография Ggg_old
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
красным выделена сервера, за которые пока никто толком не дал инфу.
...
Рейтинг: 0 / 0
Сравнение механизмов хинтования.
    #37865879
Фотография MasterZiv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Ну тогда я попробую дать за ASE.

SybaseASE: индекс(+), стратегия соединения(+), внешний план(+), Метахинты: [статистика(-), параллельность(+), допхинты(уровень оптимизации) ]


Смысл указанных пунктов полагаю следующим:

индекс -- возможность указать явно индекс для использования для таблицы.

стратегия соединения -- возможность явно задать порядок выполнения JOIN-ов в запросе. Возможность задать

внешний план -- возможность задать явно полный или частичный план запроса (частичный -- это когда какие-то параметры заданы пользователем, а остальные отдаются на выбор оптимизатора.

параллельность -- возможность

статистика -- не уверен, что имелось в виду. В ASE есть возможность использовать явно заданную статистику для запроса, но это действует для всего сервера но в рамках одной сессии, т.е. не совсем "хинты для запроса".

допхинты -- уровень оптимизации -- не понятно что такое. В ASE можно задать кол-во таблиц, участвующих в рассмотрении оптимизатором, что-то ещё такое можно тоже задать.
...
Рейтинг: 0 / 0
Сравнение механизмов хинтования.
    #37865927
MasterZivстратегия соединения -- возможность явно задать порядок выполнения JOIN-ов в запросе. Возможность задать

А к стратегии соединения относим и порядок соединения таблиц и способ их соединения?
Если так, то в MySQL можно задать порядок соединения таблиц, но нельзя задать способ.
...
Рейтинг: 0 / 0
Сравнение механизмов хинтования.
    #37868004
хинты
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
ORACLE...: индекс(+), стратегия соединения(+), внешний план(+), Метахинты: [статистика(?), параллельность(+), допхинты(см.ссылку) ]
MSSQL....: индекс(+), стратегия соединения(+), внешний план(+), Метахинты: [статистика(+), параллельность(+), допхинты(уровень оптимизации, оптимизация получения набора данных) ]
SybaseSA.: индекс(+), стратегия соединения(-), внешний план(-), Метахинты: [статистика(+), параллельность(+), допхинты(тип нагрузки запроса, уровень глубины оптимизацииб оптимизация получения набора данных) ]
SybaseASE: индекс(+), стратегия соединения(+-), внешний план(+), Метахинты: [статистика(-), параллельность(+), допхинты(уровень оптимизации) ]
DB2:.....: индекс(+), стратегии соединения(+), внешний план(+), Метахинты: [статистика(?), параллельность(?), допхинты(уровень глубины оптимизации) ]
Firebird.: индекс(-), стратегия соединения(-), внешний план(+), Метахинты: [?]
Postgres.: индекс(+-), стратегия соединения(-), внешний план(-), Метахинты: [(-) ]
MySQL....: индекс(+), стратегия соединения(+-), внешний план(-), Метахинты: [(-) ]
Informix.: индекс(?), стратегия соединения(?), внешний план(?), Метахинты: [(?) ]
...
Рейтинг: 0 / 0
Сравнение механизмов хинтования.
    #37868484
Фотография Ёш
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Не знаю подходит это под хинты, но в postgres можно для всего запроса глобально отключать способы просмотра таблиц и способы соединения таблиц, плюс управлять порядком таблиц при соединении.
...
Рейтинг: 0 / 0
Сравнение механизмов хинтования.
    #37868490
хинты
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
ЁшНе знаю подходит это под хинты, но в postgres можно для всего запроса глобально отключать способы просмотра таблиц и способы соединения таблиц, плюс управлять порядком таблиц при соединении.
А это делается глобально для запроса для сессии/соединения или для всей БД?
И если можно пример того как управлять порядком таблиц при соединении?
...
Рейтинг: 0 / 0
Сравнение механизмов хинтования.
    #37868497
Фотография Ёш
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
хинтыА это делается глобально для запроса для сессии/соединения или для всей БД?Вообще для сессии, но можно поменять обратно после запроса. Можно сделать локально для транзакции.
хинтыИ если можно пример того как управлять порядком таблиц при соединении?Нужно запретить базе менять их порядок, есть пара настроек для этого: http://www.postgresql.org/docs/current/static/explicit-joins.html
...
Рейтинг: 0 / 0
Сравнение механизмов хинтования.
    #37868915
xz321
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
1) Насколько я знаю DB2 в запросе нельзя указать хинты. Это может сделать администратор в специальном конфиге для хинтов. IMHO самый правильный подход, разработчикам которые делаюь хинты без согласования с админом на отрывать ...
2) В DB2 и Информикс статистика очень развита Куликов описывал хорошой пример Ресурсы по Informix
3) Куда в отнести DB2 WLM (Workload Management Feature) к метахинтам? Она позволяет внутри базы разным пользователям и запросам выдавать разный приоритет выполнения и количество ресурсов при обработке запроса.

ORACLE...: индекс(+), стратегия соединения(+), внешний план(+), Метахинты: [статистика(?), параллельность(+), допхинты(см.ссылку) ]
MSSQL....: индекс(+), стратегия соединения(+), внешний план(+), Метахинты: [статистика(+), параллельность(+), допхинты(уровень оптимизации, оптимизация получения набора данных) ]
SybaseSA.: индекс(+), стратегия соединения(-), внешний план(-), Метахинты: [статистика(+), параллельность(+), допхинты(тип нагрузки запроса, уровень глубины оптимизацииб оптимизация получения набора данных) ]
SybaseASE: индекс(+), стратегия соединения(+-), внешний план(+), Метахинты: [статистика(-), параллельность(+), допхинты(уровень оптимизации) ]
DB2:.....: индекс(-), стратегии соединения(-), внешний план(+), Метахинты: [статистика(+), параллельность(+), допхинты(уровень глубины оптимизации) ]
Firebird.: индекс(-), стратегия соединения(-), внешний план(+), Метахинты: [?]
Postgres.: индекс(+-), стратегия соединения(-), внешний план(-), Метахинты: [(-) ]
MySQL....: индекс(+), стратегия соединения(+-), внешний план(-), Метахинты: [(-) ]
Informix.: индекс(?), стратегия соединения(?), внешний план(?), Метахинты: [(?) ]
...
Рейтинг: 0 / 0
Сравнение механизмов хинтования.
    #37868944
Фотография Ggg_old
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
если выделяемый ресурс на выполнение запроса в дб2 влияет на построение плана, то можно отнести к метахинтам. Если не влияет - то нет.
...
Рейтинг: 0 / 0
Сравнение механизмов хинтования.
    #37869229
pkarklin
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
автор3) Куда в отнести DB2 WLM (Workload Management Feature) к метахинтам? Она позволяет внутри базы разным пользователям и запросам выдавать разный приоритет выполнения и количество ресурсов при обработке запроса.

Это не хинт (ибо не влияет на план), впрочем так же как и Resource Governоr в MS SQL.
...
Рейтинг: 0 / 0
Сравнение механизмов хинтования.
    #37869361
хинты
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
pkarklinавтор3) Куда в отнести DB2 WLM (Workload Management Feature) к метахинтам? Она позволяет внутри базы разным пользователям и запросам выдавать разный приоритет выполнения и количество ресурсов при обработке запроса.

Это не хинт (ибо не влияет на план), впрочем так же как и Resource Governоr в MS SQL.
А DB2 WLM и Resource Governor не могут влиять на степень распараллеливания (допустим при отсутствии хинта MAXDOP в MS SQL)?
...
Рейтинг: 0 / 0
Сравнение механизмов хинтования.
    #37869998
pkarklin
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
хинтыА DB2 WLM и Resource Governor не могут влиять на степень распараллеливания (допустим при отсутствии хинта MAXDOP в MS SQL)?

Нет. Только на долю процессорного времени.
...
Рейтинг: 0 / 0
Сравнение механизмов хинтования.
    #37879084
JOIN и ON
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
ЁшхинтыА это делается глобально для запроса для сессии/соединения или для всей БД?Вообще для сессии, но можно поменять обратно после запроса. Можно сделать локально для транзакции.
хинтыИ если можно пример того как управлять порядком таблиц при соединении?Нужно запретить базе менять их порядок, есть пара настроек для этого: http://www.postgresql.org/docs/current/static/explicit-joins.html
Т.е. просто в скобочками обозначаем JOIN и ON в какой последовательности они будут соединяться?
...
Рейтинг: 0 / 0
Сравнение механизмов хинтования.
    #37879202
Фотография Ёш
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
JOIN и ON, точно.
...
Рейтинг: 0 / 0
Сравнение механизмов хинтования.
    #37898205
АнатоЛой
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Ggg_oldкрасным выделена сервера, за которые пока никто толком не дал инфу.
Дам сегодня по Informix
...
Рейтинг: 0 / 0
Сравнение механизмов хинтования.
    #37898266
АнатоЛой
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Informix:
Основной источник информации тут

1. (+) индекс - метод доступа к таблице (использовать или нет конкретный индекс, избегать использования или несипользования индексов и т.д.)

2. (+) стратегия соединения

2.1. (+) порядок соединения таблиц (order)

2.2. (+) метод соединения (nested loop join, hash join)

3. (?) внешний план
Есть возможность не трогая текст запроса в приложении задать ему набор хинтов на уровне всей БД (не важно, какая сессия выполняет запрос):

Метахинты:
3.1. (?) статистика - указывать явное распределение как в МС СКЛ - не видел.


3.2. (+) параллельность

3.2.1. для схем типа звезда в запросе

3.2.2. для схем типа звезда в сессии

3.2.3. в общем для сессии

3.3. допхинты
3.3.1. (+) цель оптимизации (получить все строки запроса или только первые строки).
На уровне запроса

Можно также регулировать по умолчанию на уровне сессии или сервера .

3.3.2. (?) глубина оптимизации на уровне сессии
...
Рейтинг: 0 / 0
60 сообщений из 60, показаны все 3 страниц
Форумы / Сравнение СУБД [игнор отключен] [закрыт для гостей] / Сравнение механизмов хинтования.
Найденые пользователи ...
Разблокировать пользователей ...
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]