From: | Scott Marlowe <smarlowe(at)g2switchworks(dot)com> |
---|---|
To: | Ragnar Hafstað <gnari(at)simnet(dot)is> |
Cc: | Andreas Hartmann <andreas(at)apache(dot)org>, pgsql-general(at)postgresql(dot)org |
Subject: | Re: Massive performance differences |
Date: | 2005-03-15 18:37:38 |
Message-ID: | 1110911858.28555.155.camel@state.g2switchworks.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
On Tue, 2005-03-15 at 12:18, Ragnar Hafstað wrote:
> On Tue, 2005-03-15 at 18:10 +0100, Andreas Hartmann wrote:
>
> > explain analyze select * from veranstaltung_original order by semester;
> >
> > Sort (cost=3054.08..3067.74 rows=5467 width=223) (actual
> > time=2568.10..2573.02 rows=5467 loops=1)
> > Sort Key: semester
> > -> Seq Scan on veranstaltung_original (cost=0.00..2714.67 rows=5467
> > width=223) (actual time=1936.68..2506.83 rows=5467 loops=1)
> ^^^^^^^
> isn't this value (1936.68) suspiscious for a seq scan ?
> can a lot of dead tuples cause this?
> maybe VACUUM FULL ANALYSE time ?
It's not unreasonable for the first run when the machine has to hit the
hard drives, but if it's that slow on subsequent reads, then there's
likely some problem.
From | Date | Subject | |
---|---|---|---|
Next Message | Paul Moore | 2005-03-15 19:05:22 | Re: New user: Windows, Postgresql, Python |
Previous Message | Ragnar Hafstað | 2005-03-15 18:18:50 | Re: Massive performance differences |