| From: | Scott Marlowe <smarlowe(at)g2switchworks(dot)com> |
|---|---|
| To: | Net Virtual Mailing Lists <mailinglists(at)net-virtual(dot)com> |
| Cc: | Pgsql General <pgsql-general(at)postgresql(dot)org> |
| Subject: | Re: Peculiar performance observation.... |
| Date: | 2005-03-14 17:53:07 |
| Message-ID: | 1110822787.28555.50.camel@state.g2switchworks.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-general |
On Mon, 2005-03-14 at 06:11, Net Virtual Mailing Lists wrote:
> Hello,
>
>
> I am sorry to bring this up again.... Does anyone have any idea what
> might be going on here?... I'm very worried about this situation.. ;-(
It looks to me like either you're not analyzing often enough, or your
statistics target is too low to get a good sample. Note your estimated
versus real rows are off by a factor of 70 (28 est. versus 1943 actual
rows). That's a pretty big difference, and where you should be looking.
> > -> Seq Scan on jobdata (cost=0.00..7567.88 rows=28 width=52) (actual
> >time=11.498..4800.907 rows=1943 loops=1)
Yes, this is because PostgreSQL is using an index to approximate a
sequential scan, which is not a good thing since PostgreSQL can't get
all the information it needs from just an index, but has to visit the
table to check visibility.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Andre Maasikas | 2005-03-14 18:06:51 | Re: Checking for schedule conflicts |
| Previous Message | Chris Travers | 2005-03-14 17:50:09 | Re: sql question |