It sure would be nice if the optimizer would consider that it had the
leeway to add any column which was restricted to a single value to any
point in the ORDER BY clause. Without that, the application programmer
has to know what indexes are on the table, rather than being able to
just worry about the set of data they want. Obviously, if a column can
have only one value in the result set, adding to any point in the ORDER
BY can't change anything but performance. That sure sounds like
something which should fall within the scope of an optimizer.
It really should be a DBA function to add or drop indexes to tune the
performance of queries, without requiring application programmers to
modify the queries for every DBA adjustment. (When you have a database
with over 350 tables and thousands of queries, you really begin to
appreciate the importance of this.)
>>> Tom Lane <tgl@sss.pgh.pa.us> 06/12/05 10:56 AM >>>
Madison Kelly <linux@alteeve.com> writes:
> Here is my full query:
> tle-bu=> EXPLAIN ANALYZE SELECT file_name, file_parent_dir, file_type
> FROM file_info_7 WHERE file_type='d' ORDER BY file_parent_dir ASC,
> file_name ASC;
> This is my index (which I guess is wrong):
> tle-bu=> \d file_info_7_display_idx
> Index "public.file_info_7_display_idx"
> Column | Type
> -----------------+----------------------
> file_type | character varying(2)
> file_parent_dir | text
> file_name | text
> btree, for table "public.file_info_7"
The index is fine, but you need to phrase the query as
... ORDER BY file_type, file_parent_dir, file_name;
(Whether you use ASC or not doesn't matter.) Otherwise the planner
won't make the connection to the sort ordering of the index.
regards, tom lane
---------------------------(end of broadcast)---------------------------
TIP 9: the planner will ignore your desire to choose an index scan if
your
joining column's datatypes do not match
