RE: [HACKERS] Caution: tonight's commits force initdb
От | Hiroshi Inoue |
---|---|
Тема | RE: [HACKERS] Caution: tonight's commits force initdb |
Дата | |
Msg-id | 000501beedc2$a94bad60$2801007e@cadzone.tpf.co.jp обсуждение исходный текст |
Ответ на | Caution: tonight's commits force initdb (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Sorting costs (was Caution: tonight's commits force initdb)
|
Список | 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 по дате отправления: