Re: Performance question - Mailing list pgsql-general

On Mon, 10 Sep 2001, Stephan Szabo wrote:

> > explain SELECT Hauptdaten_Fall.MeldeKategorie,
> > Count(Hauptdaten_Fall.ID) AS Anz FROM Hauptdaten_Fall WHERE
> > (((Hauptdaten_Fall.IstAktuell)=20)) GROUP BY
> > Hauptdaten_Fall.MeldeKategorie ORDER BY
> > Hauptdaten_Fall.MeldeKategorie;
> >
> > Aggregate  (cost=35267.33..36154.62 rows=17746 width=16)
> >   ->  Group  (cost=35267.33..35710.98 rows=177458 width=16)
> >         ->  Sort  (cost=35267.33..35267.33 rows=177458 width=16)
> >               ->  Seq Scan on hauptdaten_fall  (cost=0.00..15024.12 rows=177458 width=16)
> >
> > I have nearly no experience with query optimizing but the gread difference
> > in speed tells me that something is wrong here.  There were some hints in
> > the "Index usage question" thread about some fields which might be interpreted
> > as strings.  Could this be a reason and how to check this?
>
> What's the schema for the table?

CREATE SEQUENCE SeqHauptdaten_Fall;
CREATE TABLE Hauptdaten_Fall (
    ID int DEFAULT nextval('SeqHauptdaten_Fall') ,
    InterneRef int NOT NULL ,
    Zeitstempel datetime NOT NULL ,
    ZeitStempelRKI datetime NOT NULL ,
    IstAktuell int NOT NULL ,
    IstOffen int NOT NULL ,
    IstFallDef int NOT NULL ,
    Wichtigkeit int NOT NULL ,
    ImportTyp int NOT NULL ,
    ImportStatus int NOT NULL ,
    ImportFile int NOT NULL ,
    FehlerZahl int NOT NULL ,
    ExportTyp int NOT NULL ,
    ExportStatus int NOT NULL ,
    ExportFile int NOT NULL ,
    QuittungsText text NULL ,
    Anmerkung text NULL ,
    SaveIstAktuell int NOT NULL ,
    SaveIstOffen int NOT NULL ,
    SaveExportStatus int NOT NULL ,
    FallkennungStelle varchar (15) NOT NULL ,
    FallkennungAktenzeichen varchar (50) NOT NULL ,
    FallVersion int NOT NULL ,
    MeldekennungStelle varchar (15) NULL ,
    MeldekennungAktenzeichen varchar (50) NULL ,
    MeldeKategorie varchar (10) NULL ,
    MeldeSoftware varchar (50) NULL ,
    MeldeZuordnung varchar (50) NULL ,
    Landkreis int NOT NULL ,
    MeldeJahr int NOT NULL ,
    MeldeWoche int NOT NULL ,
    PersonGeburtsJahr int NOT NULL ,
    PersonGeburtsMonat int NOT NULL ,
    GeburtstagTheoretisch datetime NULL ,
    AlterTheoretisch int NOT NULL ,
    PersonGeschlecht int NOT NULL ,
    PersonWohnsitz int NOT NULL ,
    PersonAufenthalt int NOT NULL ,
    Spende int NOT NULL ,
    ErkranktStatus int NOT NULL ,
    ErkranktDatumVon datetime NULL ,
    ErkranktDatumBis datetime NULL ,
    ErregerStatus int NOT NULL ,
    EpidemiologieStatus int NOT NULL ,
    KlinikAufenthaltStatus int NOT NULL ,
    KlinikAufenthaltDatumVon datetime NULL ,
    KlinikAufenthaltDatumBis datetime NULL ,
    KlinikAdresse int NOT NULL ,
    VerstorbenStatus int NOT NULL ,
    VerstorbenDatumVon datetime NULL ,
    VerstorbenDatumBis datetime NULL ,
    InfektionsOrt varchar (50) NULL ,
    InfektionsOKZ varchar (50) NULL ,
    InfektionsInfo text NULL ,
    HerdkennungStelle varchar (15) NULL ,
    HerdkennungAktenzeichen varchar (50) NULL ,
    MeldeDatum datetime NULL ,
    AbsenderTyp int NOT NULL ,
    Absender int NOT NULL ,
    Mediziner int NOT NULL ,
    Labor int NOT NULL ,
    WirdBetreut int NOT NULL ,
    Betreuungseinrichtung int NOT NULL ,
    IstBetreuer int NOT NULL ,
    BetreuerArbeitsstelle int NOT NULL ,
    Lebensmittel int NOT NULL ,
    LebensmittelBetrieb int NOT NULL ,
    ts timestamp NULL ,
    CONSTRAINT PK_Fall_Hauptdaten PRIMARY KEY (FallkennungStelle,FallkennungAktenzeichen,FallVersion)
) ;

CREATE   INDEX IX_IstAktuellKategorie          ON Hauptdaten_Fall(IstAktuell, MeldeKategorie);
CREATE UNIQUE INDEX IX_ID_Hauptdaten_Fall     ON Hauptdaten_Fall(ID);
CREATE  INDEX IX_MeldeJahr ON Hauptdaten_Fall(MeldeJahr);
CREATE  INDEX IX_MeldeWoche ON Hauptdaten_Fall(MeldeWoche);
CREATE  INDEX IX_Landkreis ON Hauptdaten_Fall(Landkreis);
CREATE  INDEX IX_ErkranktStatus ON Hauptdaten_Fall(ErkranktStatus);
CREATE  INDEX IX_ErregerStatus ON Hauptdaten_Fall(ErregerStatus);
CREATE  INDEX IX_EpidemiologieStatus ON Hauptdaten_Fall(EpidemiologieStatus);
CREATE  INDEX IX_KlinikAufenthaltStatus ON Hauptdaten_Fall(KlinikAufenthaltStatus);
CREATE  INDEX IX_VerstorbenStatus ON Hauptdaten_Fall(VerstorbenStatus);
CREATE  INDEX IX_ImportStatus ON Hauptdaten_Fall(ImportStatus);
CREATE  INDEX IX_ExportStatus ON Hauptdaten_Fall(ExportStatus);
CREATE  INDEX IX_ImportFile ON Hauptdaten_Fall(ImportFile);
CREATE  INDEX IX_ExportFile ON Hauptdaten_Fall(ExportFile);
CREATE  INDEX IX_Herd ON Hauptdaten_Fall(HerdkennungStelle, HerdkennungAktenzeichen);
CREATE  INDEX IX_ImportTyp ON Hauptdaten_Fall(ImportTyp);
CREATE  INDEX IX_ExportTyp ON Hauptdaten_Fall(ExportTyp);
CREATE  INDEX IX_MeldeKategorie_Hauptdaten_Fa ON Hauptdaten_Fall(MeldeKategorie);
CREATE  INDEX IX_IstFallDef ON Hauptdaten_Fall(IstFallDef);
CREATE  INDEX IX_SaveIstAktuell ON Hauptdaten_Fall(SaveIstAktuell);
CREATE  INDEX IX_FallVersion ON Hauptdaten_Fall(FallVersion);
CREATE  INDEX IX_InterneRef_Hauptdaten_Fall ON Hauptdaten_Fall(InterneRef);
CREATE  INDEX IX_IstAktuell_Hauptdaten_Fall ON Hauptdaten_Fall(IstAktuell);

> How many rows are in the table?
# select count(*) from Hauptdaten_Fall ;
 count
--------
 257530
(1 row)

> How many
> rows actually have IstAktuell=20 (is 177458 a reasonable estimate?).
Yes.
ifsg=# select count(*) from Hauptdaten_Fall WHERE IstAktuell=20;
 count
--------
 177458
(1 row)

Moreover I tried explain with:

set enable_seqscan = off;
explain SELECT Hauptdaten_Fall.MeldeKategorie, Count(Hauptdaten_Fall.ID) AS Anz FROM Hauptdaten_Fall WHERE
(((Hauptdaten_Fall.IstAktuell)=20))GROUP BY Hauptdaten_Fall.MeldeKategorie ORDER BY Hauptdaten_Fall.MeldeKategorie; 
NOTICE:  QUERY PLAN:

Aggregate  (cost=0.00..146770.97 rows=17746 width=16)
  ->  Group  (cost=0.00..146327.32 rows=177458 width=16)
        ->  Index Scan using ix_meldekategorie_hauptdaten_fa on hauptdaten_fall  (cost=0.00..145883.68 rows=177458
width=16)

I wonder, why the Index IX_IstAktuell_Hauptdaten_Fall for IstAktuell is not
used and moreover why the query takes now 127s with enable_seqscan = off
against 32s with the default setting.

Kind regards

        Andreas.