Hi,

At January 12, 2004, 08:11, Helen Borrie wrote:

> At 07:57 AM 12/01/2004 -0400, Daniel Rail wrote:

>> > I would have to wonder whether, with 3200 tables, you are experiencing a
>> > connection/schema load pause, rather than a select from the small table
>> > slowness??
>>
>>I think it might be related to the metadata on the server. The system
>>tables in FB 1.0.3 don't have indices. FB 1.5 now have indices and
>>the performance is faster when preparing a DML statement. With 3200
>>tables, the performance gain will be noticeable in FB 1.5 compared to
>>FB 1.0.3.

> I'd still go with the McDonald theory of it taking a monumental age to
> query the system tables on connection to update the client's metadata cache
> for 3200 tables.

I don't think all connection solutions performs this task on
connection. I know IBO does, but I don't think Jaybird or the ADO.Net
driver does.

> With indexes on the system tables, *that* step should be
> faster in 1.5, but it still will be a long pause on connection.

I was referring to preparing a query on the server, where the system
tables are accessed within the server itself.

> The question at hand isn't whether 1.5 is faster than 1.0.3 but whether
> querying slows down as the database gets bigger.

You're right, the discussion strayed away from the original topic. I
was just referring to the comments originally made by Paolo.

> The classic answer is "How long is a piece of string?" A squeaky-clean
> small database and a squeaky-clean large database (i.e. clear of garbage)
> should be equivalent in performance, provided each is configured with a
> dbcache appropriate to its overall size.

No arguments here.

--
Best regards,
Daniel Rail
Senior System Engineer
ACCRA Group Inc. (www.accra.ca)
ACCRA Med Software Inc. (www.filopto.com)