What happens if, say at iteration 6000 (a bit after the mess starts), you
pause it for a few minutes and resume. Will it restart with a plateau like
at the beginning of the test ? or not ?
What if, during this pause, you disconnect and reconnect, or restart the
postmaster, or vacuum, or analyze ?
On 7/18/05, Tom Lane <[EMAIL PROTECTED]> wrote:
> The table has 15 columns, 5 indexes (character, inet and timestamp).
> No foreign keys. The only other thing running on the machine was the
> application actually DOING the benchmarking, written in Python
> (psycopg), but it was, according to top, using less than 1% of the
> CPU. It was just talking through a pipe to a psql prompt to do the
> COPY.
Sounds pretty plain-vanilla all right.
Are you in a position to try the same benchmark against CVS tip?
(The nightly snapshot tarball would be plenty close enough.) I'm
just wondering if the old bgwriter behavior of locking down the
bufmgr while it examined the ARC/2Q data structures is causing this...
Tom,
It looks like the CVS HEAD is definately "better," but not by a huge
amount. The only difference is I wasn't run autovacuum in the
background (default settings), but I don't think this explains it.
Here's a graph of the differences and density of behavior:
http://blog.amber.org/diagrams/pgsql_copy_803_cvs.png
I can provide the raw data. Each COPY was 500 rows. Note that fsync
is turned off here. Maybe it'd be more stable with it turned on?
Chris
---------------------------(end of broadcast)---------------------------
TIP 4: Have you searched our list archives?
http://archives.postgresql.org
