I do have one table that acts as a lookup table and grows in size as the
app runs, however in the tests I have been doing I have dropped and
recreated all tables including the lookup table.

I keep wondering how disk is allocated to a particular DB. Also is there
any way I could tell whether the writes to disk are the bottleneck?

T.R. Missner
Level(3) Communications
SSID tools
Senior Software Engineer

-----Original Message-----
From: Matthew T. O'Connor [mailto:[EMAIL PROTECTED] 
Sent: Wednesday, July 07, 2004 1:17 PM
To: Missner, T. R.
Subject: Re: [PERFORM] inserting into brand new database faster than old

I don't think I have enough detail about your app.  Couple of questions,

are there any tables that recieve a lot of inserts / updates / deletes 
that are not deleted and recreated often?  If so, one possibility is 
that you don't have a large enough FSM settings and your table is 
actually growing despite using autovac.  Does that sounds possbile to

Missner, T. R. wrote:

> Hello,
> I have been a happy postgresql developer for a few years now.
> I have discovered a very strange phenomenon in regards to inserting
> rows.
> My app inserts millions of records a day, averaging about 30 rows a
> second. I use autovac to make sure my stats and indexes are up to
> Rarely are rows ever deleted.  Each day a brand new set of tables is
> created and eventually the old tables are dropped. The app calls
> functions which based on some simple logic perform the correct
> The problem I am seeing is that after a particular database gets kinda
> old, say a couple of months, performance begins to degrade.  Even
> creating brand new tables my insert speed is slow in comparison ( by a
> magnitude of 5 or more ) with a brand new schema which has the exact
> same tables.  I am running on an IBM 360 dual processor Linux server
> with a 100 gig raid array spanning 5 scsi disks.  The machine has 1
> of ram of which 500 meg is dedicated to Postgresql.
> Just to be clear, the question I have is why would a brand new db
> allow inserts faster than an older schema with brand new tables?
> the tables are empty to start, vacuuming should not be an issue at
> Each schema is identical in every way except the db name and creation
> date.
> Any ideas are appreciated.
> Thanks,
> T.R. Missner
> ---------------------------(end of
> TIP 9: the planner will ignore your desire to choose an index scan if
>       joining column's datatypes do not match

---------------------------(end of broadcast)---------------------------
TIP 8: explain analyze is your friend

Reply via email to