Скорость выборки

← →
Piter © (2004-12-19 16:25) [40]

Sergey_Masloff (19.12.04 15:55) [31]
ведь это dll-ка которая загружается только при запуске твоей программы. Ей свой кэш тоже надо распределять и так далее - может поэтому первый запрос с интенсивным подъемом страниц в память так тормозит

а серверу Interbase не надо в первый раз поднимать страницы в память?
К тому же - приведенные мной опыты я делал уже на сервере Firebird (использовал IBConsole) - никакой разницы между Embedded и сервером не замечено

Nikolay M. © (19.12.04 15:44) [30]
попробуй удалить индекс на n и повторить эксперимент?

Дропнул индекс по N. Запрос выполняется еще дольше:

SELECT count(n) FROM Tree WHERE n=3 :

Execution Time: 4:0672 - время увеличилось
Prepare Time: 0:0000
Delta Memory: 6144 - маленькой какой-то стала
Number of buffers: 2048
Reads: 1118 - увеличилось
Writes: 6
Plan: PLAN(TREE NATURAL)

← →
Sergey_Masloff (2004-12-19 16:25) [41]

Nikolay M. © (19.12.04 16:16) [37]
>И из-за этого план запроса требует кол-во чтений на порядок >больше
Упс... проглядел.

← →
Piter © (2004-12-19 16:28) [42]

Nikolay M. © (19.12.04 16:14) [36]
Тогда, скорее всего, остался мусор в страницах от предыдущего индекса. Удали и создай заново.

нет! Не в этом дело...

Sergey_Masloff (19.12.04 16:18) [38]
>бли-и-ин. А вы перезагружались??!?!?!

Да, и сервис перестартовывал

как вас понимать?! Что значит "И"? Как можно перезагрузить сервер и в тоже время не перестартовать сервис IB?

Sergey_Masloff (19.12.04 16:18) [38]
(хотя это уже не играет роли) компьютер перезагружал

как это не играет? Я говорю, что именно после перезагрузки первый раз тормоза, а потом уже нормально - а вы говорите не играет роли!

Sergey_Masloff (19.12.04 16:20) [39]
Ну вобщем COUNT(*) по 50 000 000 записей 52 секунды без индексов. После перезагрузки компьютера ;-)

после перезагрузки какого компьютера? Сервера надеюсь?! Или вы клиента перегружаете?!?!?!?

← →
Sergey_Masloff (2004-12-19 16:32) [43]

Piter © (19.12.04 16:25) [40]
>а серверу Interbase не надо в первый раз поднимать страницы в >память?
Надо но выделить под них место он может (и делает это) раньше - при старте.
Но неважно - сам говоришь не влияет.
Честно говоря- заинтриговал. Уже по свякому перепробовал - ну никак не влияет на результат и перегрузки компьютера, и индекс ненужный создавал, и дропал его - ну никак никакого торможения не добъюсь. Все эксперименты на таблице 6500 записей - подобрал максимально похожую.

← →
Piter © (2004-12-19 16:33) [44]

А вот на SQL.ru - хотя Николай и говорил, что там просто фантастический уровень находящегося там народа так вообще ничего путного не сказали - http://www.sql.ru/forum/actualthread.aspx?bid=2&tid=146762&pg=-1

← →
Piter © (2004-12-19 16:35) [45]

Sergey_Masloff (19.12.04 16:32) [43]
ну никак не влияет на результат и перегрузки компьютера

какого компьютера? Сервера?

Sergey_Masloff (19.12.04 16:32) [43]
Надо но выделить под них место он может (и делает это) раньше - при старте

как при старте? Имхо, при старте IB сервер вообще к таблицам не обращается. Запускается он мгновенно. И только при первом запросе из таблицы начинает ее читать. имхо.

← →
sniknik © (2004-12-19 16:38) [46]

еще пара предположений (вернее одно ;) но разные причины)

1 файл на изменениях кэшируется системой (полностью копируется весь *.gdb), в какойто из виндов такое есть, поищи на http://ibase.ru (помню чтото такое читал, не помню где. главное зависит от расширения, если поменять на *.fdb (так вроде? для фаребирда) или из системы каширований прежнее удалить, то проходит)

2 файл базы блокируется антивирусом при первом обращении (открытии).

в обшем неважно чем но блокировка, и от файрбирда она не зависит...

← →
sniknik © (2004-12-19 16:41) [47]

впрочем, у меня антивирус стоит и никаких задержек с тем же фаребирдом...
может всетаки код виноват?
выслать тестовую прогу? провериш в ней, если будет тоже самое... ну в общем любой результат показатель.

← →
Sergey_Masloff (2004-12-19 16:46) [48]

Piter © (19.12.04 16:35) [45]
>какого компьютера? Сервера?
Уже хотел ругаться что ответы не читаешь но понял что из-за глюков сервера мое огромное сообщение сюда не попало.

Придется заново. Но кратко :(
Сервер и клиент у меня один физический компьютер. После перегрузки СЕРВИСА IB его (а не операционки) кэш не существует как класс поэтому дальнейшие перезагрузки СЕРВЕРА по идее безразличны. В качестве эксперимента производилось и то и другое - то есть перестарт службы и перестарт компьютера на котором она запущена (а заодно и клиент). Все без разницы - результаты абсолютно одинаковые

>как при старте? Имхо, при старте IB сервер вообще к таблицам не >обращается. Запускается он мгновенно. И только при первом >запросе из таблицы начинает ее читать. имхо.
При старте сервер выделяет немного памяти под эти страницы. Конечно к базе он не обращается - он же не знает с какой базой будут работать клиенты. Хотя скорее вего не выделяет а просто резервирует так что на скорость это влиять не должно...

← →
Sergey_Masloff (2004-12-19 16:48) [49]

sniknik © (19.12.04 16:38) [46]
>1 файл на изменениях кэшируется системой (полностью копируется >весь *.gdb),
Это в XP только. Я сначала тоже подумал но у Питера 2000.

← →
Nikolay M. © (2004-12-19 16:50) [50]

> sniknik © (19.12.04 16:38) [46]

Я это уже в [27] предлагал...

> Piter © (19.12.04 16:28) [42]
> Nikolay M. © (19.12.04 16:14) [36]
> Тогда, скорее всего, остался мусор в страницах от предыдущего
> индекса. Удали и создай заново.
>
> нет! Не в этом дело...

А сделать базе сжатие-восстановление, если такое есть у ИБ? Или нет, сначала рядом завести тестовую таблицу аналогичной структуры и залить туда все данные из таблички? Если не поможет, создать новую базу. ы?

← →
Anatoly Podgoretsky © (2004-12-19 17:03) [51]

Piter © (19.12.04 16:02) [33]
А чего тут сомневаться, вот сейчас по немногу начинаешь рассказывать подробности и то по немногу.
Например до сих пор неизвестно имя файла сервера, например .fdb это одно, а .gdb совсем другое тут и система восстонавления может оказаться задействованой.

Например использование памяти в первом приближении можно посмотреть с помощью диспетчера задач, до запуска, дп первого запроса и после, после второго запроса и так далее. Эту информацию по использованию памяти ты не давал, и очень долго пришлось ждать прежде чем ты выдал информацию по объему памяти и винчестерам, а это все важная информация, которая может помочь в диагнозе.

По внешнем признакам или это кэш, или антивирус первый раз проверяет или система восстановления.

← →
Anatoly Podgoretsky © (2004-12-19 17:07) [52]

Piter © (19.12.04 16:33) [44]
На sql.ru хорошии специалисты, но по MS SQL
а по интербейсу и клонам лучшии на ibase.ru, но и там тоже будут гадать при такой подаче материала, хотя может быть и догадаются, попробовать то стоит?

← →
Piter © (2004-12-19 18:55) [53]

Антивируса (монитора) - нет

sniknik © (19.12.04 16:41) [47]
может всетаки код виноват?

какой код? :)

Я эксперименты проводил в IBConsole - выполнял выборки. Какой тут код?

Sergey_Masloff (19.12.04 16:46) [48]
Уже хотел ругаться что ответы не читаешь но понял что из-за глюков сервера мое огромное сообщение сюда не попало

используй мой клиент Magic Forum :)
Тогда твои посты пропадать не будут.

Sergey_Masloff (19.12.04 16:46) [48]
Сервер и клиент у меня один физический компьютер

хорошо. У меня тоже

Sergey_Masloff (19.12.04 16:46) [48]
После перегрузки СЕРВИСА IB его (а не операционки) кэш не существует как класс поэтому дальнейшие перезагрузки СЕРВЕРА по идее безразличны

Сергей! Ну что значит безразличны? Я ведь который пост говорю, что РАЗЛИЧНЫ!

Если компьютер не перезагружать - то вторичная выборка происходит за миллисекунды! При этом можно стартовать сервис IB, можно отключать его.
И с FB Embedded тоже само! По идее, он ведь при запуске каждый раз стартует? Ан нет, при повторном запуске программы все отлично, работает быстро. Тут видимо, кеширование операционки сказывается.

И только после перезагрузки в первый раз опять все медленно. Или можно не после перезагрузки - а например после интенсивной игры в какой-нибудь Call Of Duty. Тогда после выхода из игры опять выборка будет медленной в первый раз (видимо, ОС из-за игры убирает из кеша данные сервера).

Я когда проводил опыты - КАЖДЫЙ РАЗ ПЕРЕГРУЖАЛСЯ. Иначе экспериментировать не имеет смысла - время выборки при вторичных запросах очень маленькое. При этом можно хоть перегружать IB сервис, хоть нет. Да и вообще, это ведь справедливо и для FB Embedded, а там ведь при каждом запуске программы серверкак бы перезагружается.

В общем, похожая тема есть здесь - http://www.sql.ru/forum/actualthread.aspx?bid=2&tid=144344&pg=1

Nikolay M. © (19.12.04 16:50) [50]
А сделать базе сжатие-восстановление, если такое есть у ИБ?

Backup-Restore что ли? Есть такое у FB...

Sergey_Masloff (19.12.04 16:48) [49]

предлагаю провести эксперимент. Итак, делаем новую таблицу:

Create Table TestTable ( n integer not null, TestI integer not null, TestI2 integer not null, TestBlob blob not null, TestDE DOUBLE PRECISION not null, TestSI smallint, TestVC varchar(100), TestVC2 varchar (50) )

Заполняем ее рандомными значениями. Я написал программу, вот ее исходники:
http://www.newmail.ru/messages/file.dhtml?file=www.piter007.newmail.ru/other/test_fill.zip

Листинг:

function RandomString(MaxCount: integer): string; var i: integer; begin Randomize; SetLength( Result, Random(MaxCount) + 1 ); for i := 1 to Length(Result) do Result[i] := chr( Random(30) + 60 ) ; end; procedure TForm1.Button1Click(Sender: TObject); var i: integer; begin IBDatabase1.DatabaseName := EditBaseName.Text ; IBDatabase1.Open ; with IBQuery1 do begin SQL.Clear ; SQL.Add( "INSERT INTO " + EditTableName.Text + " (n, TestI, TestI2, TestBlob, TestDE, TestSI, TestVC, TestVC2) VALUES" + " (:pn, :pTestI, :pTestI2, :pTestBlob, :PTestDE, :pTestSI, :pTestVC, :pTestVC2)" ); Randomize ; for i := 1 to StrToInt( EditInsertCount.Text ) do begin ParamByName("pn").AsInteger := Random(4); ParamByName("pTestI").AsInteger := Random(999999); ParamByName("pTestI2").AsInteger := Random(50); ParamByName("pTestBlob").AsBlob := RandomString(700); ParamByName("pTestDE").AsInteger := Random(9999999); ParamByName("pTestSI").AsInteger := Random(100); ParamByName("pTestVC").AsString := RandomString(90); ParamByName("pTestVC2").AsString := RandomString(40); ExecSQL ; end; IBTransaction1.Commit ; end; end;

После заполнения таблицы 10000 записями - ПЕРЕЗАГРУЖАЕМ компьютер-сервер.
После чего, у меня выполнение
SELECT Count(n) FROM TestTable WHERE n=3
происходит чуть более секунды.

И это немного странно. С одной стороны, это явно меньше 3-4-х секунд в моем реальном примере, а с другой стороны здесь и общее, и при условии n=3 число записей больше. Число записей больше, а отрабатывает быстрее...
Новую таблицу я создавал прямо в своей реальной рабочей базе.

Но зато в реальной таблице число полей больше - может, в этом дело? Интересно...

← →
Piter © (2004-12-19 18:59) [54]

Anatoly Podgoretsky © (19.12.04 17:03) [51]
вот сейчас по немногу начинаешь рассказывать подробности и то по немногу

я рассказал все, что считал нужным. Откуда я знаю что рассказывать? Может быть, имеет значение положение каталога с windows? Откуда я знаю? Вы справшивайте - я отвечаю.

Anatoly Podgoretsky © (19.12.04 17:03) [51]
Например до сих пор неизвестно имя файла сервера, например .fdb это одно, а .gdb

.gdb

Anatoly Podgoretsky © (19.12.04 17:03) [51]
тут и система восстонавления может оказаться задействованой.

в win2000?

Anatoly Podgoretsky © (19.12.04 17:03) [51]
По внешнем признакам или это кэш, или антивирус первый раз проверяет или система восстановления.

как я понял, это будет наблюдаться у любых систем. Можете проверить - тестовый пример я выложил.

← →
Sergey_Masloff (2004-12-19 21:12) [55]

Piter © (19.12.04 18:55) [53]
Частично мне удалось повторить твой эксперимент. После перезагрузки компьютера первая выборка из твоей таблицы идет медленнее - почти в 6 раз но конечно даже о секунде речи не идет:

------ Performance info ------
Prepare time = 0ms
Execute time = 94ms
Avg fetch time = 94.00 ms
Current memory = 669 216
Max memory = 701 848
Memory buffers = 2 048
Reads from disk to cache = 848
Writes from cache to disk = 6
Fetches from cache = 15 431

В таблице 6500 записей сейчас проверяю одну идею.

← →
Anatoly Podgoretsky © (2004-12-19 21:19) [56]

Piter © (19.12.04 18:59) [54]
Вы справшивайте - я отвечаю.
Это твоя задача задавать вопросы :-)

.gdb
В этом и может быть проблема, по рекомендация от производителей серверов этого типа, рекомендуется сменить расширение на .fdb, поскольку может быть снижение производительности именно того типа, которое ты и описываешь. Файлы .gdb являются системными и поэтому система их может (с делает) сохранять для восстановления.

в win2000?
Я не знаю если в в win2000 система восстановления или нет, но она есть даже на WinMe.

← →
Sergey_Masloff (2004-12-19 21:21) [57]

Piter © (19.12.04 18:55) [53]
>предлагаю провести эксперимент. Итак, делаем новую таблицу:
Секундочку! У тебя что Primary Key в таблице нет? И в той на которой экспериментируешь ты - тоже? ;-)

Отвечай срочно ;-)

← →
AlterEgo of WondeRu © (2004-12-19 23:47) [58]

Sergey_Masloff (19.12.04 21:21) [57]
Отвечай срочно ;-)
отвечу за него: нет!!! причем PK нет ни в одной таблице его базы!

← →
Piter © (2004-12-20 00:15) [59]

Anatoly Podgoretsky © (19.12.04 21:19) [56]
не знаю если в в win2000 система восстановления или нет

по-моему, нет

Sergey_Masloff (19.12.04 21:21) [57]
У тебя что Primary Key в таблице нет? И в той на которой экспериментируешь ты - тоже?

видимо, нету :( Я привел SQL выражения для создания чистой таблицы. Привел программу заполнения этой таблицы. Больше ничего не делал...

А-а-а, чувствую меня сейчас будут бить... ногами...

Sergey_Masloff (19.12.04 21:12) [55]
но конечно даже о секунде речи не идет

а ты count делал? Или просто выборку select * ?
А то просто второй вариант и у меня быстро отрабатывает. А вот count...

← →
AlterEgo of WondeRu © (2004-12-20 00:25) [60]

Piter © (20.12.04 0:15) [59]
а ты count делал? Или просто выборку select * ?
А то просто второй вариант и у меня быстро отрабатывает. А вот count...
чего голову морочишь? делай просто селект и проверяй Query1.RecordCount! и делай PK!

← →
Anatoly Podgoretsky © (2004-12-20 00:43) [61]

Piter © (20.12.04 00:15) [59]
Срочно убегай :-)

← →
Anatoly Podgoretsky © (2004-12-20 00:47) [62]

Кстати для подоьного запроса сервер может посчитать необходимым построить временный индекс или что ни будь другое сделать.
SELECT Count(n) From MyTable Where n=0

← →
sniknik © (2004-12-20 01:12) [63]

> А то просто второй вариант и у меня быстро отрабатывает. А вот count...
странно, у меня count работает на порядок быстрее чем полный селект. (так и должно в приципе)

задержка на первом есть, но не 4 сек, это точно... повторил предложенный код (чуть переделал под ADO. привычнее)
первый запуск предложенного селекта с count(*) около сек. (0,73 показало) второй 0,06.
в принципе логично, у меня не сервер, embeded, значит время на подгрузку dll, чтение страниц базы. нормально в общем...
при добавленом индексе время меньше но не намного, гдето 0,6 и 0,04 (всетаки влияет)
а вот простой селект с выборкой всех записей гдето 4 сек и даже немного больше получается (с ограничением n=3 0.66)

кстати интересно если сделать такую же таблицу в другой базе, и по ходу переключится с базы на базу то время первого селекта на ней сокращается с 0,6 (это уже с индексом) до 0,4сек. (меньше на время подгрузки dll ?)

← →
Sergey_Masloff (2004-12-20 08:28) [64]

Anatoly Podgoretsky © (20.12.04 00:47) [62]
>Кстати для подоьного запроса сервер может посчитать необходимым >построить временный индекс или что ни будь другое сделать.
Да временный индекс строится (потому что если в такую таблицу, уже заполненую, добавлять полный дубликат записи она скажет - как минимум одна запись с такими полями есть. И скажет не задумываясь). Правда мне не хватает знаний чтобы понять как этот индекс может оставаться доступным после перестарта сервиса IB и использующего его приложения. Нет, что страницы в кеше ОС невытеснены это понятно. Но что они доступны приложению...

← →
ЗВМ (2004-12-20 08:57) [65]

А ты пускай выборку в потоке, программа запуститься сразу. А эти 4 секунды показывай заставку :)). Это на тот случай если ты не решишь данную проблему :)

← →
Sergey_Masloff (2004-12-20 09:19) [66]

Итак предварительное резюме.
testtable
testtable2

две одинаковые по структуре таблицы (то что привел Piter и добавлено поле ID заполненое уникальными значениями). В таблице testtable2 объявлен первичный ключ по полю ID. Больше НИЧЕМ таблицы не отличаются.

Результаты ПЕРВОГО селекта после перестарта КОМПЬЮТЕРА

TESTTABLE2
Plan
PLAN (TESTTABLE2 NATURAL)

Adapted Plan
PLAN (TESTTABLE2 NATURAL)

------ Performance info ------
Prepare time = 0ms
Execute time = 68ms
Avg fetch time = 68.00 ms
Current memory = 674 260
Max memory = 758 924
Memory buffers = 2 048
Reads from disk to cache = 944
Writes from cache to disk = 6
Fetches from cache = 15 586

Таблица без ПК (в 2 раза дольше)

Plan
PLAN (TESTTABLE NATURAL)

Adapted Plan
PLAN (TESTTABLE NATURAL)

------ Performance info ------
Prepare time = 0ms
Execute time = 125ms
Avg fetch time = 125.00 ms
Current memory = 674 448
Max memory = 758 924
Memory buffers = 2 048
Reads from disk to cache = 920
Writes from cache to disk = 6
Fetches from cache = 16 359

То есть 3 секунды все равно не получаем то таблица с PK все равно стабильно обрабатывается БЫСТРЕЕ. Причем статистика примерно одинаковая так что потери времени скорее всего не на запросе а именно на чем-то типа построения индекса.

← →
Sergey_Masloff (2004-12-20 09:28) [67]

Да результат воспроизводимый - с PK всегда ощутимо быстрее при похожей статистике.

← →
jack128 © (2004-12-20 11:48) [68]

Нефига не понимаю. PLAN (TESTTABLE2 NATURAL) С какого боку тут влияет наличие или отсутствие ПК?

← →
Nexel (2004-12-20 12:01) [70]

Тэкс есть у меня инфа но это только для BDE! Вообщето когда работаем через жоп.. простите BDE то вначале (при ПЕРВОМ обращении) опрашивается структура и прочая "нужная" информация и кешируется далее пока TDatabase.Connected:=True то обращение идет просто мгновенно, чтобы юзать этот кэш повторно нужно в жоп... простите BDE указать следующее
SHEMA CACHE=True
CACHE DIR=Bla..bla..bla...
НО ПРИ ЛЮБОМ ИЗМЕНЕНИИ СТРУКУРЫ ТАБЛИЦ ВСЕ СОДЕРЖИМОЕ CACHE DIR надо удалять к ЕДРЕНИ ФЕНИ!

← →
Sergey_Masloff (2004-12-20 15:51) [71]

jack128 © (20.12.04 11:48) [68]
>Нефига не понимаю. PLAN (

Нам надо перебрать всю таблицу. Ее записи разбросаны по разным (непоследовательным) страницам IB. Теоретически серверу нужно было бы перебрать ВСЕ страницы данных и смотреть по каждой записи не из нужной ли она таблицы. Это небыстро если в базе не одна таблица.
Поэтому NATURAL это проход по индексу первичного ключа с последующими быстрыми обращениями к уже известным страницам данных с нужными записями.
Так как тут ПК нет IB наверняка сроит индекс и боюсь что по всем полям сразу что конечно тоже скорости не добавляет. Конечно на 100% я это не знаю но предположение это с высокой степенью достоверности.
Кстати смотри - у Piter база около 25 мег у меня едва 3 (тольк тестовые таблицы в основном). У него первая выборка 3-4 секунды у меня гораздо меньше но все же больше последующих. Тоже ведь укладывается в теорию.

Вопрос к Piter: а что там у нас с антивирусниками ? Какой (какие) стоЯт ?
У меня стоИт Касперский. Так к тормозам при первом обращении к серверу я привык в общем-то..;(

Не хотел говорить свое мнение, но думаю, что здесь не последнюю роль играет системный файловый кэш.

При первом чтении начитывается в кэш - поэтому долго.
При следующих обращениях работа идет уже с данными в памяти+отложенная запись на диск.
Это же может происходить при

Piter © (19.12.04 18:55) [53]

...И только после перезагрузки в первый раз опять все медленно. Или можно не после перезагрузки - а например после интенсивной игры в какой-нибудь Call Of Duty. Тогда после выхода из игры опять выборка будет медленной в первый раз (видимо, ОС из-за игры убирает из кеша данные сервера)...

Мое мнение такое...

← →
Sergey_Masloff (2004-12-20 17:03) [74]

Alexander Panov © (20.12.04 16:52) [73]
>Не хотел говорить свое мнение, но думаю, что здесь не последнюю >роль играет системный файловый кэш.
Возможно, но тут вопрос почему такое поведение не удается повторить на других машинах? Файловый кэш ИМХО примерно одинаково работает везде. Заявляемых пациентом ;-) 3-4 секунд повторить не удалось. Причем не поднимается же весь файл в кеш - только определенные страницы. А вот почему при такой же таблице у Piter нужно больше страниц в памяти - мы и обсуждаем.
Сам Piter молчит. Заведение PK помогло или нет - вот в чем вопрос! ;-)

Sergey_Masloff (20.12.04 17:03) [74]
Файловый кэш ИМХО примерно одинаково работает везде.

В разных системах по-разному, все-таки.
Еще надо учесть наличие других работающих программ в данный момент, использование ими памяти. от настроек системы тоже зависит.

Т.е. в точности повторить эксперимент не удастся.

Если только на голой системе.

AlterEgo of WondeRu © (20.12.04 0:25) [60]
чего голову морочишь? делай просто селект и проверяй Query1.RecordCount!

типа это быстрей отработает? Фигня, не может быть такого...

Piter © (20.12.04 20:07) [76]
типа это быстрей отработает? Фигня, не может быть такого...
не я же сказал: "А то просто второй вариант и у меня быстро отрабатывает. А вот count...
"

← →
Sergey_Masloff (2004-12-20 20:56) [78]

Допрос продолжается :-)

sniknik © (20.12.04 1:12) [63]
задержка на первом есть, но не 4 сек, это точно

ну на тестовой таблице у меня тоже не 4 секунды, а меньше, около секунды. На реальной 4 секунды, но там полей больше.

sniknik © (20.12.04 1:12) [63]
первый запуск предложенного селекта с count(*) около сек. (0,73 показало) второй 0,06.

и у меня тоже самое. Только не 0,73 - а ближе к секунде

при добавленом индексе время меньше но не намного

аналогично

Sergey_Masloff (20.12.04 9:19) [66]
Prepare time = 0ms
Execute time = 125ms

даже учитывая, что таблицы без ПК - поразительные результаты... Может, у тебя таблица не как у меня? Сделай таблицу точно такой структуры как я написал. И заполни ее 10.000 записями по алгоритму программы, которую я выложил.

Sergey_Masloff (20.12.04 17:03) [74]
Возможно, но тут вопрос почему такое поведение не удается повторить на других машинах?

почему же? У Sniknik очень похожие результаты. А вот твои результаты мне нравятся гораздо больше, если бы у меня так было... но мне просто кажется, что ты экспериментируешь на другой таблице, более простой для подсчета. Попробуй таблицу, которую использовал Sniknik и я.

Alexander Panov © (20.12.04 16:52) [73]
При первом чтении начитывается в кэш - поэтому долго.
При следующих обращениях работа идет уже с данными в памяти+отложенная запись на диск

несомненно. Вопрос в другом - почему первый раз так долго?

sniknik © (20.12.04 1:12) [63]
странно, у меня count работает на порядок быстрее чем полный селект. (так и должно в приципе)

а попробуй еще раз - мне кажется ты ошибся. Ибо даже на SQL.ru писали, что count(*) поднимает всю таблицу и кеширует ее.

По крайней мере, у меня первый count(*) на тестовой таблице длится секунду. На реально - четыре секунды.
А вот SELECT * происходит практически мгновенно.

Скорость выборки Найти похожие ветки