Sorry for the missing info. The statements I'm executing return about
20 rows of data. The table it is fetching from has something like 15
columns. I don't think this is so very large. What is most curious
to me is the fact that the delay on commit is almost always *exactly*
10,0000ms. This sounds like a 10 second timeout in some subsystem,
but I can't see where. I tried a packet sniffer, but there's no
unusual traffic during the long commit.

Thanks!
- Dave


--- In firebird-support@yahoogroups.com, Helen Borrie <helebor@t...>
wrote:

> At 12:07 AM 6/11/2003 +0000, you wrote:
> >If rollback has the same overhead as commit, then there must be
> >something else going on here, because when I switched it to rollback,
> >the 10 second delay went away.
>
> Rollback has *more* overhead (on the server) than commit...but,

yeah, it

> could be that InterClient mudges rollback so it *doesn't* cause the

balance

> of the output set to be fetched. That would precisely account for

the time

> difference between commit and rollback.
>
> And of course updates and deletes to single records are fast: you

are just

> submitting a single statement and there is no traffic after it
> completes. You need to compare apples with apples.
>
> I still think you are not telling us the **most relevant** fact:

the size

> of the output set that your select statement will fetch eventually.

The

> 10-second delay on commit is a strong clue that it is very, very large.
>
> Helen