Subject | Re: Why it's soo slow ? it's just a very simple select ... |
---|---|
Author | nathanelrick |
Post date | 2012-03-06T19:13:08Z |
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 ??
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 firebird-support@yahoogroups.com, "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
> >
>