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

From: wieck(at)debis(dot)com (Jan Wieck)
To: genov(at)digsys(dot)bg (Stoyan Genov)
Cc: pgsql-sql(at)postgreSQL(dot)org, pgsql-novice(at)postgreSQL(dot)org
Subject: Re: [SQL] Optimizing a query through its syntax and indices
Date: 1999-11-03 17:16:33
Message-ID: m11j41R-0003kLC@orion.SAPserv.Hamburg.dsh.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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(at)debis(dot)com (Jan Wieck) #

In response to

Browse pgsql-sql by date

  From Date Subject
Next Message omid omoomi 1999-11-04 01:28:19 Re: [SQL] Copying databases
Previous Message Stoyan Genov 1999-11-03 15:45:44 Optimizing a query through its syntax and indices