On Thu, 2004-11-18 at 22:55, Tom Lane wrote:
> Josh Berkus <josh@agliodbs.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
