Re: Help on my database performance

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

In response to

Responses

Browse pgsql-performance by date

  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