Hi OC, Your problem description smell like an IO contention. BTW, this is not FB exclusive, all database will have the same kind of behaviour.
If the is no index for the where condition, you force a table scan (read all the table rows to validate the condition). If the row data in memory, this is fast, if it need to be read from disk, speed can vary a lot depending on the precise amount of data in cache and disk usage art this moment. The size of your row data can also create an amplification of this problem (few int VS many timestamps and char columns for example or if you fetch large blob). If you are on very fast PCIe SSD, it is usually very fast but regular HDs have a very limited IO capacity. Regards, Samuel > Le 15 juill. 2024 à 09:33, OCsite via Webobjects-dev > <webobjects-dev@lists.apple.com> a écrit : > > Hi there, > > for years and years, we happily use FrontBase. Lately though we are bumping > into somewhat weird behaviour: we observe inexplicably long fetches, even > with tables which are not extremely big, no joins, trivial conditions. What's > even more intriguing is that in sql92, it was much faster. Even so, the > problem was at the FB (not application) side, for an index did help > tremendously. Does not make really sense to me, and I wonder whether there > might be some weird problem in the FB itself, which might raise its head soon > and bite us hard. > > - the table contains about 16 000 rows, that's not too many; > - the fetch condition is trivial, just WHERE SOME_BOOLEAN_COLUMN = false; > - the number of found rows is only 13 currently (and never exceeded 100). > > These fetches took seconds — usually about 1200 ms, not once below 1000, > occasionally almost 3000 ms. > > When I've tried the very same fetch in sql92, it was instantaneous, which > feels pretty weird too and lead me to a suspicion that the problem is at the > application side. > > Nevertheless it was not: I just have added an index for the column, and the > fetches are ways quicker now (usually below 30 ms). > > What intrigues me and the reason I write this mail, it does not seem to me > reasonable that a plain fetch from a table of ~16K rows which yields > (considerably) less than 100 result rows, without any join and with a > completely trivial condition, could (without an index) take that long. Does > it make any sense to you, who understand SQL/FB better than me? Is that > normal? There are other fetches from the same table, with considerably more > complex conditions, taking at worst a couple tenths of second; that seems > normal to me. > > Thanks and all the best, > OC > > _______________________________________________ > Do not post admin requests to the list. They will be ignored. > Webobjects-dev mailing list (Webobjects-dev@lists.apple.com) > Help/Unsubscribe/Update your Subscription: > https://lists.apple.com/mailman/options/webobjects-dev/samuel%40samkar.com > > This email sent to sam...@samkar.com
_______________________________________________ Do not post admin requests to the list. They will be ignored. Webobjects-dev mailing list (Webobjects-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
