Subject | Re: [firebird-support] slow query at first execution |
---|---|
Author | Marco Parmeggiani |
Post date | 2004-04-28T12:04:05Z |
In data Wed, 28 Apr 2004 21:17:02 +1000, hai scritto:
1.1 insert row, on user demand, with those values setted at null
1.2 I/O request that gives those values
1.3.1 if the I/O fails, delete the row (very rare)
1.3.2 update those values
2. send response to user
2. update, on user demand, the row (the user confirms data received)
the row has some foreign keys; basically the insert is done to be sure that
all those FK are respected. this is because i must reduce to the minimum
the probability that the values obtained by the I/O cannot be written
because some other column does not respect a FK (i have also unique values
to be respected and concurrent inserts). the check is made in this way
because the operation must be quick and checking every dependency before
inserting is not enough quick.
data coming from I/O is unique.
rows with null values are in the order of 10/20 not more because if i
cannot set them i delete the row and i have a maximum of 10/20 concurrent
insert.
the delay has been noticed also with only one user active at the moment of
starting reusing the software, so there was no load at all on the db
server.
ciao
> At 01:12 PM 28/04/2004 +0200, you wrote:unfortunately no because:
>
>>no. it's more elaborated.
>>the row is inserted.
>>then, on demand, is retrieved using an alternate key (the primary key is
>>not known by who make the request) to perform an update.
>>in normal conditions this happens some seconds after the insert.
>>sometimes, it happens some days later.
>>i have an index on the alternate key (the key is made up by 2 fields, a
>>varchar and an integer).
>
> A UNIQUE index?
>
1.1 insert row, on user demand, with those values setted at null
1.2 I/O request that gives those values
1.3.1 if the I/O fails, delete the row (very rare)
1.3.2 update those values
2. send response to user
2. update, on user demand, the row (the user confirms data received)
the row has some foreign keys; basically the insert is done to be sure that
all those FK are respected. this is because i must reduce to the minimum
the probability that the values obtained by the I/O cannot be written
because some other column does not respect a FK (i have also unique values
to be respected and concurrent inserts). the check is made in this way
because the operation must be quick and checking every dependency before
inserting is not enough quick.
data coming from I/O is unique.
rows with null values are in the order of 10/20 not more because if i
cannot set them i delete the row and i have a maximum of 10/20 concurrent
insert.
the delay has been noticed also with only one user active at the moment of
starting reusing the software, so there was no load at all on the db
server.
ciao