Hi
> -----Original Message-----
> From: owner-pgsql-hackers@postgreSQL.org
> [mailto:owner-pgsql-hackers@postgreSQL.org]On Behalf Of Tom Lane
> Sent: Saturday, August 21, 1999 12:58 PM
> To: pgsql-hackers@postgreSQL.org
> Subject: [HACKERS] Caution: tonight's commits force initdb
>
>
> I have just committed changes that alter the representation of
> SortClause nodes (making them like GroupClause, instead of the
> crufty way they were done before). This breaks stored rules!
> You will need to initdb next time you pull current sources...
>
> The good news is that the optimizer is finally reasonably smart
> about avoiding a top-level Sort operation.
>
Thanks for your good jobs.
After applying this change,I tested some cases.
For a table t,explain shows
explain select * from t;
NOTICE: QUERY PLAN:
Seq Scan on t (cost=1716.32 rows=27131 width=612)
And with ORDER BY clause
explain select * from t order by key;
NOTICE: QUERY PLAN:
Index Scan using t_pkey on t (cost=2284.55 rows=27131 width=612)
Hmm,Index scan is chosen to select all rows.
AFAIK,sequential scan + sort is much faster than index scan in
most cases.
cost of index scan < cost of sequential scan + cost of sort
I have felt that the current cost estimation of index scan is too small,
though I have no alternative.
Comments ?
Hiroshi Inoue
Inoue@tpf.co.jp
