Re: Re: Performance degradation in PostgreSQL 7.1beta3 vs - Mailing list pgsql-hackers

From Hannu Krosing
Subject Re: Re: Performance degradation in PostgreSQL 7.1beta3 vs
Date
Msg-id 3A65DD5E.F3326E90@tm.ee
Whole thread Raw
In response to Re: Re: Performance degradation in PostgreSQL 7.1beta3 vs  (bruc@stone.congenomics.com (Robert E. Bruccoleri))
Responses Re: Re: Performance degradation in PostgreSQL 7.1beta3 vs
List 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 by date:

Previous
From: Zeugswetter Andreas SB
Date:
Subject: AW: AW: AW: AW: Re: tinterval - operator problems on AI X
Next
From: Thomas Lockhart
Date:
Subject: Re: Re: tinterval - operator problems on AIX