Martin Simmons wrote:
> The schema you used for the native types would be useful to know too...
Oh, sorry, I thought I included it. Schema follows, but first:
I just tested COPY ... WITH BINARY in PostgreSQL as well.
Results:
Base64 Expanded Diff %
Dump size 1679111554 2323408248 644296694 38
Import time 211 274 63 30
So expanding the fields is a significant slowdown when using WITH
BINARY. As such, I guess it's not parsing the numbers that takes the
time. In fact, I no longer have any idea what might be slowing things
down. I almost wonder if it's just disk I/O reading the files - I'll
have to try this from a machine with gigabit where I can pop the files
on a different host.
Importing using COPY ... WITH BINARY isn't actually significantly faster
than importing from tab-separated text. In fact, the expanded case is
*SLOWER* from "with binary" than the text form. That seems REALLY
strange to me. I'm going to repeat the tests a few times and poke around
a bit, because I don't get it.
Anyway, the expanded schema:
CREATE TABLE file2 (
fileid bigint,
fileindex integer,
jobid integer,
pathid integer,
filenameid integer,
markid integer,
st_dev integer,
st_ino integer,
st_mod integer,
st_nlink integer,
st_uid integer,
st_gid integer,
st_rdev bigint,
st_size integer,
st_blksize integer,
st_blocks integer,
st_atime integer,
st_mtime integer,
st_ctime integer,
linkfi integer,
md5 text
);
------------------------------------------------------------------------------
This SF.net email is sponsored by:
High Quality Requirements in a Collaborative Environment.
Download a free trial of Rational Requirements Composer Now!
http://p.sf.net/sfu/www-ibm-com
_______________________________________________
Bacula-users mailing list
Bacula-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-users
