RE: [HACKERS] Caution: tonight's commits force initdb - Mailing list pgsql-hackers

From Hiroshi Inoue
Subject RE: [HACKERS] Caution: tonight's commits force initdb
Date
Msg-id 000501beedc2$a94bad60$2801007e@cadzone.tpf.co.jp
Whole thread Raw
In response to Caution: tonight's commits force initdb  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Sorting costs (was Caution: tonight's commits force initdb)
List pgsql-hackers
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 


pgsql-hackers by date:

Previous
From: The Hermit Hacker
Date:
Subject: Re: [MIRRORS] Attempt to crack ftp site
Next
From: Tatsuo Ishii
Date:
Subject: Re: [HACKERS] vacuum process size