Re: Patch LWlocks instrumentation

> Have you looked at the total execution time with and without the
> LWLOCK_TIMING_STATS?
It didn't show any significant overhead on the little COPY test I made.  
On selects, it probably does (just like EXPLAIN ANALYZE), but I didn't  
test.It is not meant to be always active, it's a #define, so I guess it would  
be OK though.
I'm going to modify it according to your suggestions and repost it (why  
didn't I do that first ?...)

> Not that this changes your conclusion.  With or without that distortion I
> completely believe that WALInsertLock is the bottleneck of parallel bulk
> copy into unindexed tables.  I just can't find anything else it is a  
> primary
> bottleneck on.  I think the only real solution for bulk copy is to call
> XLogInsert less often.  For example, it could build blocks in local  
> memory,
> then when done copy it into the shared buffers and then toss the entire
> block into WAL in one call.  Easier said than implemented, of course.
Actually,
http://archives.postgresql.org/pgsql-hackers/2009-09/msg00806.php