Re: [SQL] Optimizing a query through its syntax and indices - Mailing list pgsql-sql

From wieck@debis.com (Jan Wieck)
Subject Re: [SQL] Optimizing a query through its syntax and indices
Date
Msg-id m11j41R-0003kLC@orion.SAPserv.Hamburg.dsh.de
Whole thread Raw
In response to Optimizing a query through its syntax and indices  (Stoyan Genov <genov@digsys.bg>)
List 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 by date:

Previous
From: Stoyan Genov
Date:
Subject: Optimizing a query through its syntax and indices
Next
From: "Hamid Khoshnevis"
Date:
Subject: Copying databases