From: | Manfred Koizar <mkoi-pg(at)aon(dot)at> |
---|---|
To: | "Jianshuo Niu" <jniu(at)wc-group(dot)com> |
Cc: | pgsql-performance(at)postgresql(dot)org |
Subject: | Re: Help on my database performance |
Date: | 2003-07-31 19:13:07 |
Message-ID: | 97qiivonvj5brg9q7ale1033fp53rupi54@4ax.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
On Thu, 31 Jul 2003 11:06:09 -0400, "Jianshuo Niu" <jniu(at)wc-group(dot)com>
wrote:
>I ran the same explain analyze on two similar tables. However, the table
>with less data took much more time than the one with more data. Could anyone
>tell me what happened?
>Seq Scan on tfd_catalog (cost=0.00..43769.82 rows=161282 width=10) (actual
>time=3928.64..12905.76 rows=161282 loops=1)
>Total runtime: 13240.21 msec
>
>Seq Scan on hm_catalog (cost=0.00..22181.18 rows=277518 width=9) (actual
>time=21.32..6420.76 rows=277518 loops=1)
>Total runtime: 6772.95 msec
The first SELECT takes almost twice the time because tfd_catalog has
almost twice as many pages than hm_catalog. This may be due to having
wider tuples or more dead tuples in tfd_catalog.
In the former case theres not much you can do.
But the high startup cost of the first SELECT is a hint for lots of
dead tuples. So VACUUM FULL ANALYSE might help.
Servus
Manfred
From | Date | Subject | |
---|---|---|---|
Next Message | Scott Cain | 2003-07-31 19:26:40 | EXTERNAL storage and substring on long strings |
Previous Message | Vivek Khera | 2003-07-31 18:57:14 | Re: Tuning PostgreSQL |