yes Rick, but what will be my job after :( i will be fired because i will become useless :(
but what the specialist will say me here ? yes it's a true disaster, the index entries are spawn in the record page, mean that if your row is 32k (for exemple) then it's will be dammed sloww, not to retrieve the record, just to read the index because index will use very lot of pages ... or it's a bug in firebird ! anyway the answer will not help ! here i just want to point that this behavior is not acceptable for a good database engine ! and how do you want to pay a specialist just to answer this simple question ?? it's not possible, we will need a DBA at full time ... but ok, if someone have some assistance offer, i will study it (in private please, [email protected]) --- In [email protected], "Benno" <iblist@...> wrote: > > Hi Rick, > > I have seen a lot of mails from you passing in this list, regarding your > database and the way you use it (transactions use etc). Looking at the size > you write about, I guess it is a database in a professional environment. > > If I were you I would spend a few dollars and consult one of the guru's to > have a look at your database together with you. Using internet and tools like > Teamviewer that should be easy manageable and I believe there are some > Firebird people in France also. > > My experience is that spending a couple of hundred dollars on a specialist > takes away a lot of frustration, is a fast learning experience since you > learn from them and helps your project move forward with a multitude of your > investment. > > > Benno > > > ----- Original Message ----- > From: nathanelrick > To: [email protected] > Sent: Tuesday, March 06, 2012 8:13 PM > Subject: [firebird-support] Re: Why it's soo slow ? it's just a very simple > select ... > > > > no one have any explanation ? > > what i don't understand is that in select IDObj From DESCRIPTION where > ID='ID_NOT_EXIST' the speed is slow when no record are founded (so the number > of field/size in table Description must not matter, only the size of the > index) ! but it's not the case, i do several test to confirm it .... > > so it's mean that the data of the index is stored INSIDE the page of the > reccord ?? > > --- In [email protected], "nathanelrick" <nathanelrick@> > wrote: > > > > Dear Mark, > > > > > Quite simple: with a field of VARCHAR(10000) on 8K pages it needs to > read > > > at least two pages if the VARCHAR is filled for over 80%, for smaller > > > VARCHARs there is still a relatively high chance it will need to read 2 > > > pages. For page sizes of 16K this is less, but still relatively high > > > (especially if the field is filled for a large percentage). If there are > > > multiple record versions that need to be processed even more pages need > to > > > be read. Reading more pages => more IO => more time. > > > > > > YEs this i understand, but what i don't understand is that in my select > (select IDObj From DESCRIPTION where ID='ID_NOT_EXIST') the speed is the same > ! :( here normally no data page must be read (because no row was found), only > page used by the index must be read ? > > > > I also try with blob, unfortunatly nothing change, just a little little > (around 10%) more faster with blob :( > > > > > > > > > > > > > > BTW: Try to use BLOBs instead of VARCHAR(10000), it might reduces this > > > problem > > > > > > Mark > > > > > > > > > > > [Non-text portions of this message have been removed] >
