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
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
