SQLite generating the "create index" SQL DDL statement at the end of the
.dump output is the correct behaviour.
In my experience using a number of different DBMSs, the sequence of data
loading and then indexing is usually quicker than performing those
operations the other way round. In a commercial environment, it's not
unusual to have tables that contain many millions of rows and have a number
of indexes (perhaps 10 or more) associated with them. Inserting a row into
such a table becomes almost a trivial exercise for the DBMS compared to
work it has to perform to maintain that many indexes for so much data.
As is usually the case, those that design and maintain SQLite have probably
got it right.
Regards.
rayB
|---------+---------------------------->
| | Steven Van |
| | Ingelgem |
| | <[EMAIL PROTECTED]> |
| | |
| | 09/09/2004 15:12 |
| | Please respond to|
| | sqlite-users |
| | |
|---------+---------------------------->
>------------------------------------------------------------------------------------------------------------------------------|
|
|
| To: [EMAIL PROTECTED]
|
| cc:
|
| Subject: [sqlite] sqlite.exe binary (windows)
|
>------------------------------------------------------------------------------------------------------------------------------|
I just noticed something rather stupid...
when you .dump a table via the sqlite.exe binary (2.8.15)... It dumps first
the "create table", then the "insert"s, and afterwards the indexes....
Now if you have a very big table it will take a LOT of time to place those
indexes... Maybe it is more performant to place the "create index" just
after the "create table" statement?
Greetings,
KaReL (aka Steven)
Main Webpage : http://www.karels0ft.be/
ICQ # : 35217584
******************* Confidentiality and Privilege Notice *******************
This e-mail is intended only to be read or used by the addressee. It is
confidential and may contain legally privileged information. If you are not
the addressee indicated in this message (or responsible for delivery of the
message to such person), you may not copy or deliver this message to anyone,
and you should destroy this message and kindly notify the sender by reply
e-mail. Confidentiality and legal privilege are not waived or lost by reason
of mistaken delivery to you.
Qantas Airways Limited
ABN 16 009 661 901
Visit Qantas online at http://qantas.com
****************************************************************************
