> > 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 results time 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
---------------------------(end of broadcast)---------------------------
TIP 2: Don't 'kill -9' the postmaster
