Re: 8.x index insert performance

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Kelly Burkhart <kelly(at)tradebotsystems(dot)com>
Cc: pgsql-performance(at)postgresql(dot)org
Subject: Re: 8.x index insert performance
Date: 2005-11-11 00:13:28
Message-ID: 13167.1131668008@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

Kelly Burkhart <kelly(at)tradebotsystems(dot)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

In response to

Responses

Browse pgsql-performance by date

  From Date Subject
Next Message Tom Lane 2005-11-11 00:32:46 Re: Index Scan Costs versus Sort
Previous Message Charlie Savage 2005-11-11 00:11:48 Re: Index Scan Costs versus Sort