I used Zeos to test to know: is ZTable uses fetch technics, or not?
May in the future we migrate our lesser system to PGSQL, and this used now “Table” components (as BDE, but it have an SQL-like server).
These tables use real cursors, a “Window” with N record, so lookup is very fast, because the Locate/Lookup is started on server, and only these N records are refreshed, no matter, how many records in the lookup table.
PGSQL uses fetch technics as I know, and I tested it with a table (id int, name varchar(100)), and 1 million records. (I also trying this with mysql). The adapter is Zeos.
ID, sec to find, allocated memory in bytes on client.
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
As you see the records are fetched locally, this cause the 225 MB usage, and searches are slow a little, based where is the record we must find.
I want to ask more things:
a.)
Is PGDAC have some technics to we can use the lookups without pay the fetch with memory and secs?
b.)
Or is PG ODBC driver can help in this problem with ADO? (As I know ADO can use server side cursors)?
c.)
Have anybody some experience with lookup tables, and performance? Is this critical question or it is not?
(With client memory usage too).
d.)
If no chance to avoid fetch hell with lookups, what we can do?
Server Side Joins, and unique code for Lookup field changing without real Lookup?
Thanks for your help:
dd
The developers answered me:
So there is not SS cursor now.
Thanks:
dd