From: | Simon Riggs <simon(at)2ndquadrant(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | josh(at)agliodbs(dot)com, pgsql-hackers(at)postgresql(dot)org, testperf-general(at)pgfoundry(dot)org |
Subject: | Re: [Testperf-general] Re: ExclusiveLock |
Date: | 2004-11-20 08:38:59 |
Message-ID: | 1100900912.3388.12.camel@localhost.localdomain |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Thu, 2004-11-18 at 22:55, Tom Lane wrote:
> Josh Berkus <josh(at)agliodbs(dot)com> writes:
> >> The main problem on INSERTs is that it is usually the same few pages:
> >> the lead data block and the lead index block. There are ways of
> >> spreading the load out across an index, but I'm not sure what happens on
> >> the leading edge of the data relation, but I think it hits the same
> >> block each time.
>
> > I actually have several test cases for this, can you give me a trace or
> > profile suggestion that would show if this is happening?
>
> If it is a problem, the LockBuffer calls in RelationGetBufferForTuple
> would be the places showing contention delays.
You say this as if we can easily check that. My understanding is that
this would require a scripted gdb session to instrument the executable
at that point.
Is that what you mean? That isn't typically regarded as a great thing to
do on a production system.
You've mentioned about performance speculation, which I agree with, but
what are the alternatives? Compile-time changes aren't usually able to
be enabled, since many people from work RPMs.
> It could also be that the contention is for the WALInsertLock, ie, the
> right to stuff a WAL record into the shared buffers. This effect would
> be the same even if you were inserting into N separate tables.
...and how do we check that also.
Are we back to simulated workloads and fully rigged executables?
--
Best Regards, Simon Riggs
From | Date | Subject | |
---|---|---|---|
Next Message | Reini Urban | 2004-11-20 09:00:22 | Re: [HACKERS] Beta5 Scheduale |
Previous Message | Thomas Hallgren | 2004-11-20 07:53:08 | Re: Error handling in plperl and pltcl |