Re: 8.x index insert performance - Mailing list pgsql-performance

From Tom Lane
Subject Re: 8.x index insert performance
Date
Msg-id 13167.1131668008@sss.pgh.pa.us
Whole thread Raw
In response to Re: 8.x index insert performance  (Kelly Burkhart <kelly@tradebotsystems.com>)
Responses Re: 8.x index insert performance
List pgsql-performance
Kelly Burkhart <kelly@tradebotsystems.com> writes:
> ...  A graph showing the performance
> characteristics is here:

> <http://kkcsm.net/pgcpy.jpg>

I hadn't looked at this chart till just now, but it sure seems to put a
crimp in my theory that you are running out of room to hold the indexes
in RAM.  That theory would predict that once you fall over the knee of
the curve, performance would get steadily worse; instead it gets
markedly worse and then improves a bit.  And there's another cycle of
worse-and-better around 80M rows.  I have *no* idea what's up with that.
Anyone?  Kelly, could there be any patterns in the data that might be
related?

The narrow spikes look like they are probably induced by checkpoints.
You could check that by seeing if their spacing changes when you alter
checkpoint_segments and checkpoint_timeout.  It might also be
entertaining to make the bgwriter parameters more aggressive to see
if you can ameliorate the spikes.

            regards, tom lane

pgsql-performance by date:

Previous
From: Charlie Savage
Date:
Subject: Re: Index Scan Costs versus Sort
Next
From: Tom Lane
Date:
Subject: Re: Index Scan Costs versus Sort