Re: [SQL] Optimizing a query through its syntax and indices

Поиск
Список
Период
Сортировка
От wieck@debis.com (Jan Wieck)
Тема Re: [SQL] Optimizing a query through its syntax and indices
Дата
Msg-id m11j41R-0003kLC@orion.SAPserv.Hamburg.dsh.de
обсуждение исходный текст
Ответ на Optimizing a query through its syntax and indices  (Stoyan Genov <genov@digsys.bg>)
Список pgsql-sql
>
>
> Hello,
>
> I talk PostgreSQL 6.5.2 ...
>
> Suppose we have some tables we join using some of their fields.
> Suppose there are "restrictions" for the values of some (or all) of the tables'
> fields of this kind:
>    tableM.fieldN [ NOT ] IN (constA,constB,constC),
>    tableP.fieldQ [ NOT ] IN (constD,constE,constF),
>    etc...
> These restrictions can occur for the fields by which we join the tables, as well
> as for fields of tables we do not use for joins.
>
> Are there (can there be) general ( or not so general :-) ) rules for optimizing
> the query ( and the performance and the speed ) through the particular order we
> put the join statements in the WHERE clause, trough mixing/ordering the join
> parts and the restrictions ( in the means defined above ) in the values of the
> fields in the WHERE clause, through changing the syntax ( for example, using
> UNION or EXCEPT clauses ), or through using one- or more-than-one-field
> indices, or through doubling some of the restrictions if they refer to a
> field we join by ( for example, "... WHERE tableM.fieldN = tableP.fieldQ and
> tableM.fieldN in (constA,constB)" complemented by " and tableP.fieldQ in (constA
> ,constB)" ).
>

    The  last part, complementing the qualifications, is known to
    speedup  the  join  significantly.  At   least   for   simple
    expressions  that  can be put down into the scan itself. This
    is because it reduces the amount  of  data  before  the  join
    already.  Don't  know if this is true for IN expressions too,
    so you might give it a try (and report the result back to us,
    please).

    There  had  been  the idea to do this automatically in a step
    between rewriting and planning. Unfortunately noone seems  to
    have the time to tackle it.


Jan

--

#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me.                                  #
#========================================= wieck@debis.com (Jan Wieck) #

В списке pgsql-sql по дате отправления:

Предыдущее
От: Stoyan Genov
Дата:
Сообщение: Optimizing a query through its syntax and indices
Следующее
От: "Hamid Khoshnevis"
Дата:
Сообщение: Copying databases