Yes, I understand very clearly what you mean.
Maybe my mails were to confused, that's why I try to explain my problem once more:
step 1. An empty table with a primary key (=index key) where an "explain" tells me,
that a Seq Scan is used to SELECT a special row.
step 2. Then I start to fill dat
Andreas Wernitznig <[EMAIL PROTECTED]> writes:
> The only way to make it faster after step 3 is to close that connection (and stop
>that postmaster thread with it) and establish a new one.
> It seems like the planner (at least for pk checking) of an *established* connection
>to a database doesn'
Andreas Wernitznig <[EMAIL PROTECTED]> writes:
> To make it more comparable I have made two additional runs, a slow and
> a fast one with exactly the same number of inserts (about 20500) and
> put it on our ftp server:
>> However, I think what is happening is that some queries are being done
>> a
On Wed, 22 Aug 2001 19:19:42 -0400
Tom Lane <[EMAIL PROTECTED]> wrote:
> Andreas Wernitznig <[EMAIL PROTECTED]> writes:
> > I took option 1 and managed to create a profile of a slow and a fast run:
>
> It's difficult to compare these profiles, because they seem to be taken
> over very different
Do you have any index on the tables ? Any triggers ?
If you want to insert 1 million rows you should drop the index, insert the data and
then recreate the index.
You should also try the COPY command to insert the data.
You should also avoid having anyone to connect to the database when you inse
Andreas Wernitznig <[EMAIL PROTECTED]> writes:
> I took option 1 and managed to create a profile of a slow and a fast run:
It's difficult to compare these profiles, because they seem to be taken
over very different numbers of queries --- did you let the "fast" run
process more queries than the "s
I took option 1 and managed to create a profile of a slow and a fast run:
The frequent functions of the FAST run:
% cumulative self self total
time seconds secondscalls Ts/call Ts/call name
0.00 0.00 0.00 15725437 0.00 0.00 Al
Andreas Wernitznig <[EMAIL PROTECTED]> writes:
> I am aware of the performance drawbacks because of indices and
> triggers. In fact I have a trigger and an index on the most populated
> table. It is not possible in my case to remove the primary keys
> during insert, because the database structure
I am aware of the performance drawbacks because of indices and triggers. In fact I
have a trigger and an index on the most populated table.
It is not possible in my case to remove the primary keys during insert, because the
database structure and foreign keys validate my data during import.
Th
