hi NikhilS.
2008/3/14, NikhilS [EMAIL PROTECTED]:
Hi Longlong,
i think this is a better idea.
from *NikhilS *
http://archives.postgresql.org/pgsql-hackers/2007-12/msg00584.php
But instead of using a per insert or a batch insert substraction, I am
thinking that we can start off a
Hi Longlong,
i think this is a better idea.
from *NikhilS *
http://archives.postgresql.org/pgsql-hackers/2007-12/msg00584.php
But instead of using a per insert or a batch insert substraction, I am
thinking that we can start off a subtraction and continue it till we
encounter a failure.
2008/3/12, Neil Conway [EMAIL PROTECTED]:
I don't see why creating index entries in bulk has anything to do with
COPY vs. INSERT: if a lot of rows are being loaded into the table in a
single command, it would be a win to create the index entries in bulk,
regardless of whether COPY or INSERT
i want to paticipate in gsoc 2008.
here is my plan:
the red part is came from Greg Smith(thanks for Greg Smith's advice).
1.release8.2 make COPY TO can copy the output of an arbitrary SELECT
statement. so i think maybe COPY FROM can get data from output and 'insert
into' some column that
On Tue, 2008-03-11 at 20:56 +0800, longlong wrote:
This would be a nice feature. Right now there are often applications
where there is a data loading or staging table that ends up being
merged with a larger table after some cleanup. Moving that data from
the preperation area into the final
On Tue, 2008-03-11 at 15:18 -0700, Neil Conway wrote:
Note also that pg_bulkload currently does something analogous to this
outside of the DBMS proper:
http://pgbulkload.projects.postgresql.org/
Sorry, wrong project. I mean pgloader:
http://pgfoundry.org/projects/pgloader/
-Neil
--
-- Forwarded message --
From: longlong [EMAIL PROTECTED]
Date: 2008-3-12 9:42
Subject: Re: [HACKERS]COPY issue(gsoc project)
To: Neil Conway [EMAIL PROTECTED]
the first feature has been implementet. i used to ignore the pid column with
the command copy tablename (columns) from
