Re: Query Performance...

From: jhood(at)hmcon(dot)com (Jeffrey Hood)
To: pgsql-general(at)postgresql(dot)org
Subject: Re: Query Performance...
Date: 2002-07-21 20:48:55
Message-ID: a2c11736.0207211248.13d6a2e3@posting.google.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

> > explain
> > select r.dateissued, r.medication, p.lastname, p.dob
> > from rx r
> > inner join patient p on r.patientid = p.patientid
> > where r.dateissued between '7/13/02' and '7/14/02';
>
> > Merge Join (cost=237899.24..250302.47 rows=24895698 width=64)
> > -> Sort (cost=8590.77..8590.77 rows=2515 width=32)
> > -> Index Scan using idx_rx_date_issued on rx r
> > (cost=0.00..8448.70 rows=2515 width=32)
> > -> Sort (cost=229308.47..229308.47 rows=989743 width=32)
> > -> Seq Scan on patient p (cost=0.00..35256.43 rows=989743
> > width=32)
>
> > How does one get rid of the table scan on patient in the second...???
>
> The only *possible* alternative to a seqscan on patient would be to use
> a nestloop with inner indexscan on patient.patientid, and I'm not at all
> clear that that'd be faster than the seqscan --- it would depend on how
> many rows are actually returned by the rx scan.
>
> Have you got an index on patientid? If you set enable_seqscan = off,
> does the plan change?

There is an index on patientid... and setting enable_seqscan = off and
running explain shows that the index will be used, but running the
query, it takes the same time (45 sec) that it does with the scan...
and the same query on SQLServer and mysql runs in .5 sec... (they both
always use the index...)

Thanks,
JH

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Ewald Geschwinde 2002-07-21 21:55:38 Re: pg_dump: PG 7.0 -> PG 7.2.1
Previous Message Ralph Graulich 2002-07-21 17:40:25 Re: max relations in a single database