On 03/11/10 08:46, Mladen Gogala wrote:
I wrote a little Perl script, intended to test the difference that
array insert makes with PostgreSQL. Imagine my surprise when a single
record insert into a local database was faster than batches of 100
records. Here are the two respective routines:
I
On 10/11/10 22:10, Mark Kirkwood wrote:
What might also be interesting is doing each INSERT with an array-load
of bind variables appended to the VALUES clause - as this will only do
1 insert call per "array" of values.
This is probably more like what you were expecting:
rowsnum values t
I wrote a little Perl script, intended to test the difference that array
insert makes with PostgreSQL. Imagine my surprise when a single record
insert into a local database was faster than batches of 100 records.
Here are the two respective routines:
sub do_ssql
{
my $exec_cnt = 0;
whil
I wrote a little Perl script, intended to test the difference that array
insert makes with PostgreSQL. Imagine my surprise when a single record
insert into a local database was faster than batches of 100 records.
Here are the two respective routines:
sub do_ssql
{
my $exec_cnt = 0;
whil
Conor Walsh wrote:
I generally suspect this is a Perl problem rather than a Postgres
problem,
So do I. I had the same situation with Oracle, until John Scoles had the
DBD::Oracle driver fixed and started utilizing the Oracle array interface.
but can't say more without code. Maybe try pas
On Tue, Nov 2, 2010 at 2:32 PM, Mladen Gogala wrote:
> I was surprised because I expected array bind to produce better
> results over the network than the row-by-row operations, yet it
> didn't. Can anybody elaborate a bit?
While all of the bulk-execute functions are likely to have
implementatio
I sent 2 emails, both containing a Perl code sample, but none of them
went through. Essentially, I was testing Perl array bind & execute.
Everything went well, except for the fact that array execute is no
faster than the row-by-row way of executing things. I was surprised
because I expected arr
