Skip site navigation (1) Skip section navigation (2)

Re: Load experimentation

From: Ben Brehmer <benbrehmer(at)gmail(dot)com>
To: pgsql-performance(at)postgresql(dot)org
Cc: Thom Brown <thombrown(at)gmail(dot)com>, Kevin Grittner <Kevin(dot)Grittner(at)wicourts(dot)gov>, craig_james(at)emolecules(dot)com, kbuckham(at)applocation(dot)net, scott(dot)lists(at)enterprisedb(dot)com, Greg Smith <greg(at)2ndquadrant(dot)com>
Subject: Re: Load experimentation
Date: 2009-12-08 07:22:10
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-performance
Thanks for all the responses. I have one more thought;

Since my input data is split into about 200 files (3GB each), I could 
potentially spawn one load command for each file. What would be the 
maximum number of input connections Postgres can handle without bogging 
down? When I say 'input connection' I mean "psql -U postgres -d dbname 
-f one_of_many_sql_files".


On 07/12/2009 12:59 PM, Greg Smith wrote:
> Ben Brehmer wrote:
>> By "Loading data" I am implying: "psql -U postgres -d somedatabase -f 
>> sql_file.sql".  The sql_file.sql contains table creates and insert 
>> statements. There are no indexes present nor created during the load.
>> COPY command: Unfortunately I'm stuck with INSERTS due to the nature 
>> this data was generated (Hadoop/MapReduce).
> Your basic options here are to batch the INSERTs into bigger chunks, 
> and/or to split your data file up so that it can be loaded by more 
> than one process at a time.  There's some comments and links to more 
> guidance here at
> -- 
> Greg Smith    2ndQuadrant   Baltimore, MD
> PostgreSQL Training, Services and Support
> greg(at)2ndQuadrant(dot)com

In response to


pgsql-performance by date

Next:From: Greg SmithDate: 2009-12-08 07:35:12
Subject: Re: Load experimentation
Previous:From: Greg SmithDate: 2009-12-08 05:43:47
Subject: Re: Dynamlically updating the estimated cost of a transaction

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group