Re: insert performance for win32 - Mailing list pgsql-performance

From Merlin Moncure
Subject Re: insert performance for win32
Date
Msg-id 6EE64EF3AB31D5448D0007DD34EEB3417DD27F@Herge.rcsinc.local
Whole thread Raw
In response to insert performance for win32  (Marc Cousin <mcousin@sigma.fr>)
List pgsql-performance
> > In my experience win32 is par with linux generally with a few gotchas on
> > either side.  Are your times with fsync=no? It's much harder to give
> > apples-apples comparison with fsync=on for various reasons.
> It is with fsync=off on windows, fsync=on on linux

well, inside a transaction this shouldn't have mattered anyways.

> > Are you running stats_command_string=on?  Try disabling and compare
> > results.
> Deactivated on windows, activated on linux

> > Is your loading app running locally or on the server?
> Yes

hm :(.  Well, you had me curious so I went ahead and re-ran your test case and profiled it (on windows).  I got similar
resultstime wise.  It's interesting to note that the command I used to generate the test table before dumping w/inserts 

insert into test select nextval('test_id_seq'), 'test' from generate_series(1,500000)

ran in just a few seconds.

Well, I cut the #recs down to 50k and here is profile trace:
  %   cumulative   self              self     total
 time   seconds   seconds    calls   s/call   s/call  name
 10.78      0.62     0.62    50001     0.00     0.00  yyparse
  5.39      0.93     0.31  5101422     0.00     0.00  AllocSetAlloc
  4.52      1.19     0.26   799970     0.00     0.00  base_yylex
  2.78      1.35     0.16   299998     0.00     0.00  SearchCatCache
  2.43      1.49     0.14   554245     0.00     0.00  hash_search
  2.26      1.62     0.13    49998     0.00     0.00  XLogInsert
  1.74      1.72     0.10   453363     0.00     0.00  LWLockAcquire
  1.74      1.82     0.10   299988     0.00     0.00  ScanKeywordLookup

This makes me wonder if we are looking in the wrong place.  Maybe the problem is coming from psql?  More results to
follow.

Merlin

pgsql-performance by date:

Previous
From: Richard Huxton
Date:
Subject: Re: Poor performance of delete by primary key
Next
From: Mark Lewis
Date:
Subject: Re: Poor performance of delete by primary key