Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Сравнение СУБД Новый топик    Ответить
Топик располагается на нескольких страницах: Ctrl  назад   1 [2] 3   вперед  Ctrl      все
 Re: Сравнение механизмов хинтования.  [new]
softwarer
Member

Откуда: 127.0.0.1
Сообщений: 67475
Блог
Ggg_old
У оракла вроде как богатые возможности, но деталей и возможностей не знаю совсем.

У Оракла есть фича, называемая stored outlines - возможность зафиксировать план запроса. То есть потребовать, чтобы некий запрос всегда-всегда-всегда выполнялся именно по тому плану, который построен для него сейчас. Технически эта фича реализована через хинты - то есть для запроса сохраняется в базе набор хинтов, фиксирующих план. Думаю, это даёт представление о соотношении "умений оптимизатора вообще" и "возможностей хинтами этим управлять".
27 июн 12, 12:06    [12781557]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение механизмов хинтования.  [new]
pkarklin
Member

Откуда: Москва (Муром)
Сообщений: 74930
В MS SQL можно даже так:

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>')
27 июн 12, 12:11    [12781615]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение механизмов хинтования.  [new]
Ggg_old
Member

Откуда: Одесса
Сообщений: 1342
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.
27 июн 12, 13:38    [12782453]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение механизмов хинтования.  [new]
Ggg_old
Member

Откуда: Одесса
Сообщений: 1342
С учетом замечаний таблица выходит такая:

ORACLE...: индекс(+), стратегия соединения(+), внешний план(+), Метахинты: [статистика(?), параллельность(+), допхинты(см.ссылку) ]
DB2:.....: индекс(-), стратегии соединения(-), внешний план(+), Метахинты: [статистика(?), параллельность(?), допхинты(уровень глубины оптимизации) ]
SybaseSA.: индекс(+), стратегия соединения(-), внешний план(-), Метахинты: [статистика(+), параллельность(+), допхинты(тип нагрузки запроса, уровень глубины оптимизации) ]
MSSQL....: индекс(+), стратегия соединения(+), внешний план(+), Метахинты: [статистика(+), параллельность(+), допхинты(?) ]
Firebird.: индекс(-), стратегия соединения(-), внешний план(+), Метахинты: [?]
27 июн 12, 13:40    [12782478]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение механизмов хинтования.  [new]
Ggg_old
Member

Откуда: Одесса
Сообщений: 1342
знаком ? я указываю, что не знаю есть или нет и как оно делается, т.е. эта опция в таблице требует уточнения.
27 июн 12, 13:42    [12782492]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение механизмов хинтования.  [new]
pkarklin
Member

Откуда: Москва (Муром)
Сообщений: 74930
Ggg_old,

Я бы добавил в список хинты блокировок (Locking Hints), как отдельный класс. Довольно часто применемая фича в OLTP.
27 июн 12, 13:46    [12782524]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение механизмов хинтования.  [new]
pkarklin
Member

Откуда: Москва (Муром)
Сообщений: 74930
Ggg_old,

автор
optimization_workload option


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

optimize for ad hoc workloads

BOL
The 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

MSDN
Trace 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


FAST number_rows


BOL
Specifies 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.
27 июн 12, 14:45    [12782988]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение механизмов хинтования.  [new]
спецы по PostgreSQL
Guest
А есть спецы по PostgreSQL, как там обстоят с этим дела?
27 июн 12, 16:01    [12783685]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение механизмов хинтования.  [new]
Ggg_old
Member

Откуда: Одесса
Сообщений: 1342
Рассмтарвиаем только хинты, влияющие на план запроса. Хинты уровня изоляции транзакций, управления кэшами, кэшированием планов, и т.п. не входят в рассмотрение. Т.е. интересно только то, как SQL превращается в алгоритмы.


ORACLE...: индекс(+), стратегия соединения(+), внешний план(+), Метахинты: [статистика(?), параллельность(+), допхинты(см.ссылку) ]
DB2:.....: индекс(-), стратегии соединения(-), внешний план(+), Метахинты: [статистика(?), параллельность(?), допхинты(уровень глубины оптимизации) ]
SybaseSA.: индекс(+), стратегия соединения(-), внешний план(-), Метахинты: [статистика(+), параллельность(+), допхинты(тип нагрузки запроса, уровень глубины оптимизацииб оптимизация получения набора данных) ]
SybaseASE: индекс(+), стратегия соединения(?), внешний план(?), Метахинты: [(?) ]
MSSQL....: индекс(+), стратегия соединения(+), внешний план(+), Метахинты: [статистика(+), параллельность(+), допхинты(уровень оптимизации, оптимизация получения набора данных) ]
Firebird.: индекс(-), стратегия соединения(-), внешний план(+), Метахинты: [?]
Postgres.: индекс(?), стратегия соединения(?), внешний план(?), Метахинты: [(?) ]
Informix.: индекс(?), стратегия соединения(?), внешний план(?), Метахинты: [(?) ]
27 июн 12, 16:15    [12783802]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение механизмов хинтования.  [new]
pkarklin
Member

Откуда: Москва (Муром)
Сообщений: 74930
Ggg_old,

Ок.
27 июн 12, 16:50    [12784165]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение механизмов хинтования.  [new]
ad hoc
Guest
pkarklin
optimize for ad hoc workloads

BOL
The 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 нужно для минимизации: кэширования планов таких запросов, кэширования резалтсета, кэширования страниц базы.
А оптимизатору время на оптимизацию плана запроса выделяется больше при включении этой опции?
28 июн 12, 13:24    [12788344]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение механизмов хинтования.  [new]
pkarklin
Member

Откуда: Москва (Муром)
Сообщений: 74930
ad hoc,

Опция меняет механику генерации плана. Время не меняется.
28 июн 12, 14:44    [12788999]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение механизмов хинтования.  [new]
спецы по PostgreSQL
Guest
А вот как обстоят дела с PostgreSQL.
А в PostgreSQL что можно хинтовать?
Почему не нужно хинтование
Как считаете оно действительно не нужно?
28 июн 12, 15:13    [12789245]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение механизмов хинтования.  [new]
Ivan Durak
Member

Откуда: Minsk!!!
Сообщений: 3795
Favn
Ggg_old
Насколько я слышал, что у DB2 прямых хинтов нет, т.к. считается что оптимизатор шибко умный, но ямогу ошибаться либо мои знания устарели.
Ну, скажем так, есть, но не хинты :)
В самих запросах хинты не указываются. Обычно, если что-то не так, разбираются почему и, например, меняют уровень оптимизации, от которого зависит "вдумчивость" работы оптимизатора.

Да это практически везде так!! И в МССКЛ и даже в Оракле. Хорошо собранная статистика заменяет тонны лишних хинтов.
29 июн 12, 12:46    [12793821]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение механизмов хинтования.  [new]
MySQL хинты
Guest
Ggg_old
Рассмтарвиаем только хинты, влияющие на план запроса. Хинты уровня изоляции транзакций, управления кэшами, кэшированием планов, и т.п. не входят в рассмотрение. Т.е. интересно только то, как SQL превращается в алгоритмы.


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

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

А в MySQL есть хинты и что они могут?
1 июл 12, 03:15    [12800142]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение механизмов хинтования.  [new]
MySQL хинты
Guest

ORACLE...: индекс(+), стратегия соединения(+), внешний план(+), Метахинты: [статистика(?), параллельность(+), допхинты(см.ссылку) ]
DB2:.....: индекс(-), стратегии соединения(-), внешний план(+), Метахинты: [статистика(?), параллельность(?), допхинты(уровень глубины оптимизации) ]
SybaseSA.: индекс(+), стратегия соединения(-), внешний план(-), Метахинты: [статистика(+), параллельность(+), допхинты(тип нагрузки запроса, уровень глубины оптимизацииб оптимизация получения набора данных) ]
SybaseASE: индекс(+), стратегия соединения(?), внешний план(?), Метахинты: [(?) ]
MSSQL....: индекс(+), стратегия соединения(+), внешний план(+), Метахинты: [статистика(+), параллельность(+), допхинты(уровень оптимизации, оптимизация получения набора данных) ]
Firebird.: индекс(-), стратегия соединения(-), внешний план(+), Метахинты: [?]
Postgres.: индекс(+-), стратегия соединения(-), внешний план(-), Метахинты: [(-) ]
MySQL.: индекс(+), стратегия соединения(-), внешний план(-), Метахинты: [(-) ]
Informix.: индекс(?), стратегия соединения(?), внешний план(?), Метахинты: [(?) ]
В MySQL возможны только хинтование индексов USE/IGNORE INDEX и порядок соединения таблиц вместо JOIN пишем STRAIGHT_JOIN. Выбора стратегий соединения быть не может, т.к. там всего только одна стратегия NLJ :)
А в MySQL что можно хинтовать?
1 июл 12, 14:50    [12800521]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение механизмов хинтования.  [new]
хинты
Guest
ORACLE...: индекс(+), стратегия соединения(+), внешний план(+), Метахинты: [статистика(?), параллельность(+), допхинты(см.ссылку) ]
MSSQL....: индекс(+), стратегия соединения(+), внешний план(+), Метахинты: [статистика(+), параллельность(+), допхинты(уровень оптимизации, оптимизация получения набора данных) ]
SybaseSA.: индекс(+), стратегия соединения(-), внешний план(-), Метахинты: [статистика(+), параллельность(+), допхинты(тип нагрузки запроса, уровень глубины оптимизацииб оптимизация получения набора данных) ]
SybaseASE: индекс(+), стратегия соединения(?), внешний план(?), Метахинты: [(?) ]
DB2:.....: индекс(-), стратегии соединения(-), внешний план(+), Метахинты: [статистика(?), параллельность(?), допхинты(уровень глубины оптимизации) ]
Firebird.: индекс(-), стратегия соединения(-), внешний план(+), Метахинты: [?]
Postgres.: индекс(+-), стратегия соединения(-), внешний план(-), Метахинты: [(-) ]
MySQL....: индекс(+), стратегия соединения(-), внешний план(-), Метахинты: [(-) ]
Informix.: индекс(?), стратегия соединения(?), внешний план(?), Метахинты: [(?) ]
1 июл 12, 14:52    [12800524]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение механизмов хинтования.  [new]
Favn
Member

Откуда:
Сообщений: 585
Ggg_old
интересно только то, как SQL превращается в алгоритмы.

DB2:.....: индекс(-), стратегии соединения(-), внешний план(+), Метахинты: [статистика(?), параллельность(?), допхинты(уровень глубины оптимизации) ]
Раз пошла такая пьянка, прочел-таки документацию :)
Индексы - да, стратегии соединения - да, план - да. С планом все сложнее, потому что DB2 - компилятор, и план всегда генерится и сохраняется как результат компиляции запроса. При желании его можно фиксировать и не пересоздавать в будущем и без хинтов.
Кстати, о превращении в алгоритмы - есть возможность настроить и поведение фазы переформулирования запроса оптимизатором.
Можно в профиле хинта установить значения переменных компилятора SQL, управляющих его поведением.
Можно указать до запроса, какой профиль хинтов сейчас надо использовать.
Использование статистики, не соответствующей текущей (скажем, выгрузка-загрузка статистики из другой БД, или фиксация плана на другой момент времени) возможно, но другими механизмами.
2 июл 12, 13:39    [12803785]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение механизмов хинтования.  [new]
Ggg_old
Member

Откуда: Одесса
Сообщений: 1342

ORACLE...: индекс(+), стратегия соединения(+), внешний план(+), Метахинты: [статистика(?), параллельность(+), допхинты(см.ссылку) ]
MSSQL....: индекс(+), стратегия соединения(+), внешний план(+), Метахинты: [статистика(+), параллельность(+), допхинты(уровень оптимизации, оптимизация получения набора данных) ]
SybaseSA.: индекс(+), стратегия соединения(-), внешний план(-), Метахинты: [статистика(+), параллельность(+), допхинты(тип нагрузки запроса, уровень глубины оптимизацииб оптимизация получения набора данных) ]
SybaseASE: индекс(+), стратегия соединения(?), внешний план(?), Метахинты: [(?) ]
DB2:.....: индекс(+), стратегии соединения(+), внешний план(+), Метахинты: [статистика(?), параллельность(?), допхинты(уровень глубины оптимизации) ]
Firebird.: индекс(-), стратегия соединения(-), внешний план(+), Метахинты: [?]
Postgres.: индекс(+-), стратегия соединения(-), внешний план(-), Метахинты: [(-) ]
MySQL....: индекс(+), стратегия соединения(-), внешний план(-), Метахинты: [(-) ]
Informix.: индекс(?), стратегия соединения(?), внешний план(?), Метахинты: [(?) ]
4 июл 12, 11:39    [12814694]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение механизмов хинтования.  [new]
Ggg_old
Member

Откуда: Одесса
Сообщений: 1342
красным выделена сервера, за которые пока никто толком не дал инфу.
4 июл 12, 11:41    [12814715]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение механизмов хинтования.  [new]
MasterZiv
Member

Откуда: Питер
Сообщений: 34709
Ну тогда я попробую дать за ASE.

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


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

  • индекс -- возможность указать явно индекс для использования для таблицы.
  • стратегия соединения -- возможность явно задать порядок выполнения JOIN-ов в запросе. Возможность задать
  • внешний план -- возможность задать явно полный или частичный план запроса (частичный -- это когда какие-то параметры заданы пользователем, а остальные отдаются на выбор оптимизатора.
  • параллельность -- возможность
  • статистика -- не уверен, что имелось в виду. В ASE есть возможность использовать явно заданную статистику для запроса, но это действует для всего сервера но в рамках одной сессии, т.е. не совсем "хинты для запроса".
  • допхинты -- уровень оптимизации -- не понятно что такое. В ASE можно задать кол-во таблиц, участвующих в рассмотрении оптимизатором, что-то ещё такое можно тоже задать.
  • 4 июл 12, 12:54    [12815413]     Ответить | Цитировать Сообщить модератору
     Re: Сравнение механизмов хинтования.  [new]
    стратегии соединения
    Guest
    MasterZiv
  • стратегия соединения -- возможность явно задать порядок выполнения JOIN-ов в запросе. Возможность задать

  • А к стратегии соединения относим и порядок соединения таблиц и способ их соединения?
    Если так, то в MySQL можно задать порядок соединения таблиц, но нельзя задать способ.
    4 июл 12, 13:22    [12815703]     Ответить | Цитировать Сообщить модератору
     Re: Сравнение механизмов хинтования.  [new]
    хинты
    Guest
    ORACLE...: индекс(+), стратегия соединения(+), внешний план(+), Метахинты: [статистика(?), параллельность(+), допхинты(см.ссылку) ]
    MSSQL....: индекс(+), стратегия соединения(+), внешний план(+), Метахинты: [статистика(+), параллельность(+), допхинты(уровень оптимизации, оптимизация получения набора данных) ]
    SybaseSA.: индекс(+), стратегия соединения(-), внешний план(-), Метахинты: [статистика(+), параллельность(+), допхинты(тип нагрузки запроса, уровень глубины оптимизацииб оптимизация получения набора данных) ]
    SybaseASE: индекс(+), стратегия соединения(+-), внешний план(+), Метахинты: [статистика(-), параллельность(+), допхинты(уровень оптимизации) ]
    DB2:.....: индекс(+), стратегии соединения(+), внешний план(+), Метахинты: [статистика(?), параллельность(?), допхинты(уровень глубины оптимизации) ]
    Firebird.: индекс(-), стратегия соединения(-), внешний план(+), Метахинты: [?]
    Postgres.: индекс(+-), стратегия соединения(-), внешний план(-), Метахинты: [(-) ]
    MySQL....: индекс(+), стратегия соединения(+-), внешний план(-), Метахинты: [(-) ]
    Informix.: индекс(?), стратегия соединения(?), внешний план(?), Метахинты: [(?) ]
    5 июл 12, 16:48    [12823593]     Ответить | Цитировать Сообщить модератору
     Re: Сравнение механизмов хинтования.  [new]
    Ёш
    Member

    Откуда:
    Сообщений: 2892
    Не знаю подходит это под хинты, но в postgres можно для всего запроса глобально отключать способы просмотра таблиц и способы соединения таблиц, плюс управлять порядком таблиц при соединении.
    6 июл 12, 02:12    [12825871]     Ответить | Цитировать Сообщить модератору
     Re: Сравнение механизмов хинтования.  [new]
    хинты
    Guest
    Ёш
    Не знаю подходит это под хинты, но в postgres можно для всего запроса глобально отключать способы просмотра таблиц и способы соединения таблиц, плюс управлять порядком таблиц при соединении.

    А это делается глобально для запроса для сессии/соединения или для всей БД?
    И если можно пример того как управлять порядком таблиц при соединении?
    6 июл 12, 02:28    [12825899]     Ответить | Цитировать Сообщить модератору
    Топик располагается на нескольких страницах: Ctrl  назад   1 [2] 3   вперед  Ctrl      все
    Все форумы / Сравнение СУБД Ответить