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