From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Prajakt Deolasee <bugzilla(dot)prajakt(at)gmail(dot)com> |
Cc: | pgsql-jdbc(at)postgresql(dot)org |
Subject: | Re: Postgres is slow |
Date: | 2005-03-08 19:36:52 |
Message-ID: | 13487.1110310612@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-jdbc |
Prajakt Deolasee <bugzilla(dot)prajakt(at)gmail(dot)com> writes:
> Thanks guys.. I will try of the suggested steps. But one thing that I
> do not understand that why should the performance deteriorate with
> exactly same data with subsequent tests. And its juts gets worse as I
> keep running it.
This is surely a matter of dead-row bloat. Are you vacuuming the tables
between runs? Do you have the FSM parameters set high enough to keep
track of all the dead space you create by UPDATEs or DELETEs?
I was just looking at the "sql-bench" stuff that MySQL distributes. One
of the tests that we look particularly awful on goes like this:
* build table with 300,000 rows.
* full-table update (UPDATE foo SET col = something)
* repeat full-table update 10 times
With a VACUUM after each update, things would be fine, but since they
don't have one in the loop the table bloats to 10 times its normal size
(as do its indexes) and performance goes quickly south ... and not only
on that test, but on the subsequent ones using the same table ...
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Oliver Jowett | 2005-03-08 21:23:33 | Re: PreparedStatement#setString on non-string parameters |
Previous Message | Dave Cramer | 2005-03-08 18:17:32 | Re: Postgres is slow |