On Apr 4, 2005 10:36 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Christopher Petrilli <petrilli@gmail.com> writes:
> > On Apr 4, 2005 12:23 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> >> do a test run with *no* indexes on the table, just to see if it behaves
> >> any differently? Basically I was wondering if index overhead might be
> >> part of the problem.
>
> > http://www.amber.org/~petrilli/diagrams/pgsql_copy500_pkonly.png
>
> > I appologize, I forgot to kill the PK, but as you can see, the curve
> > flattened out a lot. It still begins to increase in what seems like
> > the same place. You can find the results themselves at:
>
> Yeah, this confirms the thought that the indexes are the source of
> the issue. (Which is what I'd expect, because a bare INSERT ought to be
> an approximately constant-time operation. But it's good to verify.)
This seemsed to be my original idea, but I wanted to eliminate
everything else as much as possible. I was also concerned that I might
be hitting a bad case in the trees. I had to change some UID
generation code to better hash, so...
> Now some amount of slowdown is to be expected as the indexes get larger,
> since it ought to take roughly O(log N) time to insert a new entry in an
> index of size N. The weird thing about your curves is the very sudden
> jump in the insert times.
Right, I expected O(log N) behavior myself, and it seems to behave
that way, if you look at the first section (although there's some
interesting patterns that are visible if you exclude data outside the
90th percentile in the first section, that seems to coincide with some
write activity.
> It would be interesting to watch the output of iostat or vmstat during
> this test run. If I'm correct about this, the I/O load should be
> basically all writes during the initial part of the test, and then
> suddenly develop a significant and increasing fraction of reads at the
> point where the slowdown occurs.
Well, I can track this on a run, if it would be useful, but I think
you're right as it matches what I saw from looking at iostat at those
points.
> The indicated fix of course is to increase shared_buffers.
Any idea where it should be set?
Chris
--
| Christopher Petrilli
| petrilli@gmail.com
