Я использовал Zeos для проверки, чтобы узнать: использует ли ZTable методику извлечения или нет?
Возможно, в будущем мы перенесем нашу меньшую систему на PGSQL, и теперь она использует компоненты "Table" (как BDE, но у него есть SQL-подобный сервер).
В этих таблицах используются настоящие курсоры, «Окно» с N-записью, поэтому поиск выполняется очень быстро, поскольку поиск / поиск запускается на сервере, и только эти N-записи обновляются, независимо от того, сколько записей в поиске стол.
PGSQL, как я знаю, использует технику выборки, и я протестировал ее с помощью таблицы (id int, name varchar (100)) и 1 миллиона записей. (Я тоже пробую это с mysql). Адаптер Zeos.
ID, сек, чтобы найти, выделенная память в байтах на клиенте.
MySQL
500000 2,761 113 196 344
1000000 3,214 225 471 232
313800 0,437 225 471 232
328066 0,468 225 471 232
276374 0,390 225 471 232
905984 1,264 225 471 232
260253 0,359 225 471 232
PGSQL
500000 3,042 113 188 184
1000000 3,744 225 463 064
313800 0,436 225 463 064
328066 0,452 225 463 064
276374 0,375 225 463 064
905984 1,295 225 463 064
260253 0,359 225 463 064
142023 0,203 225 463 064
Как вы видите, записи извлекаются локально, это приводит к использованию 225 МБ, а поиск немного медленный, в зависимости от того, где находится запись, которую мы должны найти.
Я хочу спросить больше вещей:
а.)
Есть ли у PGDAC какие-то технические приемы, чтобы мы могли использовать поиск без оплаты выборки с памятью и секундами?
б.)
Или драйвер PG ODBC может помочь в этой проблеме с ADO? (Как я знаю, ADO может использовать серверные курсоры)?
с.)
У кого-нибудь есть опыт работы со справочными таблицами и производительностью? Это критический вопрос или нет?
(С использованием памяти клиента тоже).
д.)
Если нет шансов избежать ада с поисками, что мы можем сделать?
Соединения на стороне сервера и уникальный код для поля поиска, изменяющегося без реального поиска?
Спасибо за вашу помощь:
дд