Re: Comparitive UPDATE speed

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Josh Berkus <josh(at)agliodbs(dot)com>
Cc: Andrew Sullivan <andrew(at)libertyrms(dot)info>, pgsql-performance(at)postgresql(dot)org
Subject: Re: Comparitive UPDATE speed
Date: 2002-10-04 19:41:14
Message-ID: 26113.1033760474@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

Josh Berkus <josh(at)agliodbs(dot)com> writes:
> Hash Join (cost=3076.10..91842.88 rows=108648 width=40) (actual
> time=18625.19..22823.39 rows=108546 loops=1)
> -> Seq Scan on elbs_matter_links eml (cost=0.00..85641.87 rows=117787
> width=20) (actual time=18007.69..19515.63 rows=117787 loops=1)
> -> Hash (cost=2804.48..2804.48 rows=108648 width=20) (actual
> time=602.12..602.12 rows=0 loops=1)
> -> Seq Scan on case_clients cc (cost=0.00..2804.48 rows=108648
> width=20) (actual time=5.18..370.68 rows=108648 loops=1)
> Total runtime: 22879.26 msec

Hm. Why does it take 19500 milliseconds to read 117787 rows from
elbs_matter_links, if 108648 rows can be read from case_clients in 370
msec? And why does the output show that the very first of those rows
was returned only after 18000 msec?

I am suspicious that this table has a huge number of empty pages in it,
mostly at the beginning. If so, a VACUUM FULL would help. (Try
"vacuum full verbose elbs_matter_links" and see if it indicates it's
reclaiming any large number of pages.)

If that proves to be the answer, you need to look to your FSM
parameters, and perhaps arrange for more frequent regular vacuums
of this table.

regards, tom lane

In response to

Responses

Browse pgsql-performance by date

  From Date Subject
Next Message Tom Lane 2002-10-04 19:45:28 Re: Comparitive UPDATE speed
Previous Message Andrew Sullivan 2002-10-04 19:24:15 Re: Comparitive UPDATE speed