работаю с postgresql (7.3.1) из под билдера через odbc (psqlODBC 07.02.0005)

берем например такой запрос к базе:

select * from pos, work where p_id=w_pos, возвращающий 149 записей

и измеряем время, необходимое на его выполнение (Query3->Active = true)

1 вариант: CursorLoation: clUseServer
CursorType: ctOpenForwardOnly
время - 960 мс
трафик - 41 кБ

лог файл:
conn=31406080, query='select * from pos, work where p_id=w_pos
'
[ fetched 149 rows ]
conn=31406080, PGAPI_Disconnect


2 вариант: CursorLoation: clUseClient
CursorType: ctOpenForwardOnly
время - 650 мс
трафик - 75 кБ

лог файл:
conn=31406080, query='select * from pos, work where p_id=w_pos
'
[ fetched 149 rows ]
conn=31406080, query='SELECT * FROM pos'
[ fetched 73 rows ]
conn=31406080, query='SELECT * FROM work'
[ fetched 149 rows ]
conn=31406080, query='select ta.attname, ia.attnum from pg_attribute ta, pg_attribute ia, pg_class c, pg_index i, pg_namespace n where c.relname = 'pos' AND n.nspname = 'public' AND c.oid = i.indrelid AND n.oid = c.relnamespace AND i.indisprimary = 't' AND ia.attrelid = i.indexrelid AND ta.attrelid = i.indrelid AND ta.attnum = i.indkey[ia.attnum-1] order by ia.attnum'
[ fetched 1 rows ]
conn=31406080, query='select ta.attname, ia.attnum from pg_attribute ta, pg_attribute ia, pg_class c, pg_index i, pg_namespace n where c.relname = 'work' AND n.nspname = 'public' AND c.oid = i.indrelid AND n.oid = c.relnamespace AND i.indisprimary = 't' AND ia.attrelid = i.indexrelid AND ta.attrelid = i.indrelid AND ta.attnum = i.indkey[ia.attnum-1] order by ia.attnum'
[ fetched 1 rows ]
conn=31406080, PGAPI_Disconnect

внимание вопрос: почему во втором случае быстрее???!!!
при более сложных запросах (селект из 5 таблиц) разница становится еще большей - 3 и 0.8 секунд соответственно!

процитирую себя :)
вот лог:

conn=31406080, query='SELECT * FROM pos'
[ fetched 73 rows ]
conn=31406080, query='SELECT * FROM work'
[ fetched 149 rows ]


пока записей мало, клиентский курсор работает быстрее. но учитывая то, что при выборке даже одной (!) записи odbc тащит на комп целиком все таблицы, учавствующие в запросе :( (+ еще 2 каких-то дополнительных селекта делает), то естественно на больших таблицах он работает уже медленней (пока несколько мегабайт по сетке перекачаются)...
но почему в первом случае 5 селектов быстрее одного (из тех-же пяти)?! :(

причина тормозов стала чуть яснее..
скорость выполнения запроса неожиданно сильно зависит от количества полей у результата... т.е. намного быстрее будет разбить запрос на 2 и получить сначала одну половину столбцов таблицы, а потом другую :((( бред. причем тормозит именно odbc на клиентской машине, а не postgres.
может надо было наоборот сервер делать на pIII-500 а клиентов на dual pIII-1200? :(