Thread: Optimizing a query through its syntax and indices

Optimizing a query through its syntax and indices

From
Stoyan Genov
Date:
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)" ).

I hope I was clear enough for my question to be understood.

Any help will be appretiated.

Regards,Stoyan Genov


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

From
wieck@debis.com (Jan Wieck)
Date:
>
>
> 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) #