Re: Re: Performance degradation in PostgreSQL 7.1beta3 vs
От | Hannu Krosing |
---|---|
Тема | Re: Re: Performance degradation in PostgreSQL 7.1beta3 vs |
Дата | |
Msg-id | 3A65DD5E.F3326E90@tm.ee обсуждение исходный текст |
Ответ на | Re: Re: Performance degradation in PostgreSQL 7.1beta3 vs (bruc@stone.congenomics.com (Robert E. Bruccoleri)) |
Ответы |
Re: Re: Performance degradation in PostgreSQL 7.1beta3 vs
|
Список | pgsql-hackers |
"Robert E. Bruccoleri" wrote: > > Dear Hannu, > > > > "Robert E. Bruccoleri" wrote: > > > > > > explain select count(*) from comparisons_4 where code = 80003; > > > NOTICE: QUERY PLAN: > > > > > > Aggregate (cost=15659.29..15659.29 rows=1 width=0) > > > -> Seq Scan on comparisons_4 (cost=0.00..15640.81 rows=7391 width=0) > > > > > > EXPLAIN > > > > What is the type of field "code" ? > > int4 > > Do you think that should make a difference? Probably not here. Sometimes it has made difference if the system does not recognize the other side of comparison (80003) as being of the same type as the index. what are the cost estimates when you run explain with seqscan disabled ? do => SET ENABLE_SEQSCAN TO OFF; see: (http://www.postgresql.org/devel-corner/docs/admin/runtime-config.htm#RUNTIME-CONFIG-OPTIMIZER) ----------------- Hannu
В списке pgsql-hackers по дате отправления: