Skip site navigation (1) Skip section navigation (2)

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 (view raw or flat)
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

pgsql-performance by date

Next:From: Scott CainDate: 2003-07-31 19:26:40
Subject: EXTERNAL storage and substring on long strings
Previous:From: Vivek KheraDate: 2003-07-31 18:57:14
Subject: Re: Tuning PostgreSQL

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group