Just to add some clarity to the Dawid's fine comments:
On 4/14/05, Dawid Kuroczko <[EMAIL PROTECTED]> wrote:
> On 4/13/05, Matt Van Mater <[EMAIL PROTECTED]> wrote:
> I believe that COPY handles things like unique constraints and
> referer integerity just fine (of the latter I am not sure) -- well
On 4/13/05, Matt Van Mater <[EMAIL PROTECTED]> wrote:
> > The intent of prepared statements is to reduce the overhead of running
> > the parser, rewriter and planner multiple times for a statement that is
> > executed multiple times. For an INSERT query without any sub-selects
> > that is not rewri
On Wed, Apr 13, 2005 at 09:57:09AM -0400, Matt Van Mater wrote:
> Also, I forgot to mention earlier that I tried using transactions to
> speed things up, but since I expect to see certain inserts fail I
> would need to rework my code so the whole transaction doesn't fail if
> one insert goes bad.
On Apr 13, 2005, at 9:57 AM, Matt Van Mater wrote:
Thanks to all who replied. Thanks for the tip on that last thread
Tom, I don't know how I missed it. I have a hunch that it's not
applicable to me at this time because I'm running a year and a half
old software (included in OpenBSD 3.4), but I wi
Neil Conway <[EMAIL PROTECTED]> writes:
> The intent of prepared statements is to reduce the overhead of running
> the parser, rewriter and planner multiple times for a statement that is
> executed multiple times. For an INSERT query without any sub-selects
> that is not rewritten by any rules,
Neil Conway wrote:
> For an INSERT query without any sub-selects
> that is not rewritten by any rules, the cost to parse, rewrite and plan
> the statement is trivial. So I wouldn't expect prepared statements to be
> a big win -- you would gain a lot more from batching multiple inserts
On Wed, Apr 13, 2005 at 09:57:09 -0400,
Matt Van Mater <[EMAIL PROTECTED]> wrote:
>
> Also, I forgot to mention earlier that I tried using transactions to
> speed things up, but since I expect to see certain inserts fail I
> would need to rework my code so the whole transaction doesn't fail if
>
Thanks to all who replied. Thanks for the tip on that last thread
Tom, I don't know how I missed it. I have a hunch that it's not
applicable to me at this time because I'm running a year and a half
old software (included in OpenBSD 3.4), but I will have to check which
version of DBD::Pg was insta
Dawid Kuroczko wrote:
For a test you might want to try also this approach (both from perl and
from psql):
$dbh->do('PREPARE sth_tim (int,inet,boolean,timestamptz) AS INSERT
INTO timestamps VALUES ($1,$2,$3,$4)');
$sth_tim = $dbh->prepare("EXECUTE sth_tim(?,?,?,?)");
...and later execute it. (and
On Apr 13, 2005, at 4:12 AM, Dawid Kuroczko wrote:
On 4/12/05, Matt Van Mater <[EMAIL PROTECTED]> wrote:
I've been experimenting with loading a large amount of data into a
fairly simple database using both psql and perl prepared statements.
Unfortunately I'm seeing no appreciable differences betwee
On 4/12/05, Matt Van Mater <[EMAIL PROTECTED]> wrote:
> I've been experimenting with loading a large amount of data into a
> fairly simple database using both psql and perl prepared statements.
> Unfortunately I'm seeing no appreciable differences between the two
> methods, where I was under the im
Matt Van Mater <[EMAIL PROTECTED]> writes:
> I've been experimenting with loading a large amount of data into a
> fairly simple database using both psql and perl prepared statements.
> Unfortunately I'm seeing no appreciable differences between the two
> methods, where I was under the impression t
I've been experimenting with loading a large amount of data into a
fairly simple database using both psql and perl prepared statements.
Unfortunately I'm seeing no appreciable differences between the two
methods, where I was under the impression that prepared statements
should be much faster (in m
13 matches
Mail list logo
