Re: Re: Performance degradation in PostgreSQL 7.1beta3 vs

From: Hannu Krosing <hannu(at)tm(dot)ee>
To: bruc(at)acm(dot)org
Cc: tgl(at)sss(dot)pgh(dot)pa(dot)us, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Re: Performance degradation in PostgreSQL 7.1beta3 vs
Date: 2001-01-17 17:58:54
Message-ID: 3A65DD5E.F3326E90@tm.ee
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Camm Maguire 2001-01-17 18:49:20 Re: Mysterious 7.0.3 error
Previous Message Mikheev, Vadim 2001-01-17 17:25:49 RE: DeadLockCheck is buggy