# post backup & restore
# time isql < q.count.sql

COUNT
============
129599


real 0m0.382s
user 0m0.014s
sys 0m0.049s

# pre backup & restore
# time isql < q.count.sql

COUNT
============
129599


real 0m4.932s
user 0m0.014s
sys 0m0.042s

the query is "select count(*) from mytable"

as all the records were added in a script together I expect they would all
be on close pages

It is worth noting that the performance deteriorated to 4.8 sec, initially
it was around the 0.3, I need to understand why in order to keep it at 0.3

On 30 July 2013 10:50, Dmitry Kuzmenko <kdv@...> wrote:

> **
>
>
> Hello, Nick!
>
> Tuesday, July 30, 2013, 1:41:21 PM, you wrote:
>
> NU> gstat -r output:
>
> NU> pre backup/restore
>
> you again checked select * from table at that moment?
> and it is 4.8 sec?
>
> NU> post backup/restore
> and here - 0.3 sec?
>
> NU> I obviously expect some improvement from backup/restore but 15x seems
> more
> NU> than can be accounted for
>
> I doubt that your measures are correct.
> Since I see 130k records, I think that
> 4.8 seconds of select * from table
> takes FetchAll, i.e. transferring all records to client application.
>
> And, 0.3 seconds for the same query on 130k records
> means that FetchAll is not in effect, ony some parts of records
> are being read.
>
> Or, (which is a bit suspicious), your hard drive is very slow
> at random reads, if at first case this table pages were fragmented
> in the DB.
>
> --
> Dmitry Kuzmenko, www.ib-aid.com
>
>
>



--
Nick Upson, Telensa Ltd


[Non-text portions of this message have been removed]