Subject | Re: [firebird-support] insert speeds are slow |
---|---|
Author | Luc Belliveau |
Post date | 2005-06-22T12:28:07Z |
PFK = Primary Foreign Key
When I was doing my tests in PHP I was using prepared statements, and
that was still too slow; which is why I moved directly on the server
with isql to test. There are no triggers on the table, the only thing I
can think of now is having multiple primary keys.. so I just tried
creating the same table without keys, the same statements run in less
than 1 minute; so evidently having 3 primary foreign keys creates a
significant amount of internal overhead.
Luc
When I was doing my tests in PHP I was using prepared statements, and
that was still too slow; which is why I moved directly on the server
with isql to test. There are no triggers on the table, the only thing I
can think of now is having multiple primary keys.. so I just tried
creating the same table without keys, the same statements run in less
than 1 minute; so evidently having 3 primary foreign keys creates a
significant amount of internal overhead.
Luc
On Wed, 2005-06-22 at 00:47 +0200, Milan Babuskov wrote:
> Luc Belliveau wrote:
> > I'm trying to a table with 3 columns, all PFKs
>
> What is a PFK?
>
> >, with 102117 rows. First
> > I tried getting a stored procedure to do it, but found it was way too
> > slow. I assumed the problem was with the way I was collecting the
> > information to add (which involves some recursion), so I wrote a php
> > script to collect the information, that takes about 9 seconds, then
> > tried to do inserts from there. That was also much too slow
>
> You could deactivate indexes and primary/foreign keys, but I'm not sure
> this is the problem. Use prepared statements: in PHP via ibase_prepare
> and ibase_execute functions. I don't know what is the machine you're
> using, but 100.000 rows should load below one minute on most systems. I
> just tried with one table (via FBExport) and it inserted 282651 rows in
> 119 seconds. That table has 9 fields (chars, numerics and timestamp).
>
> Also, you may want to check if you have some complex triggers on that
> table which could slow this down significantly.
>