VladoТянуть записи с сервера по одной можно юзая DECLARE CURSOR и FETCH.
Но производительности это не поможет.Поможет. Поможет ускорить выдачу первых строк результата. Мы эту возможность раньше использовали на полную катушку. (Сейчас не используем, потому что кардинально ускорили поиск.) Вот пример. select count(*) from plprice_00;
count
---------
3463267
(1 row)

# explain analyze select * from plprice_00 where prod ilike '%ipaq%4700%' order by plno;
QUERY PLAN
--------------------------------------------------------------------------------------------------------------------------------------------
Index Scan using pk_prc_plno_00 on plprice_00 (cost=0.00..391011.03 rows=222 width=640) (actual time= 1627 .10.. 113337 .00 rows=475 loops=1)
Filter: (prod ~~* '%ipaq%4700%'::text)
Total runtime: 113338.70 msec
(3 rows)То есть первую строку постргес может отдать через полторы секунды, и последнюю - через две минуты.
vfabrможно примерчик, а то очень интересно как это сделать.Вроде бы так:$ time perl -e 'print "begin;\n"; print "declare c_plprice_00_0001 cursor for select * from plprice_00 where prod ilike \x27%ipaq%4700%\x27 order by plno;\n"; print "fetch forward 1 from c_plprice_00_0001;\n";' | psql -U pl -d pl
real 0m2.152s
user 0m0.010s
sys 0m0.000s

vfabrда действительно можно наверное извлекать строки пока не выполнился весь запрос ... хотя многое зависит от оптимизатора и тпДа, можно. А оптимизатор надо пинать ногами, чтобы не мешал. :) (С помощью set enable_* to [on,off].) В приведенном мною примере в плане выполнения запроса нет Sort-а, хотя в тексте запроса Order By присутствует. Строки выдаются в требуемом порядке возрастания plno благодаря тому, что запрос работает по индексу (Index Scan) на plno (pk_prc_plno_00), а не по таблице (Seq Scan).
AntonIggСкорее всего получить первую строку возможно, если в запросе нет агрегирующих функций и order by и т.п.Быстро получить первые строки можно и в запросах с group by и order by. Для этого нужно, например, чтобы первая часть выражения в order by совпадала с выражением в group by, и чтобы существовал индекс первая часть которого совпадала бы с выражением в order by: index(f1,f2,f3,f4) group by f1,f2 order by f1,f2,f3 или index(f1,f2) group by f1,f2 order by f1,f2.

vfabrну я думаю что тогда (в случае настройки оптимизатора) вся остальная выборка будет делаться медленее (в большинстве случаев)да, зачастую так может получиться:
# set enable_seqscan to on;
SET
# explain analyze select * from plprice_00 where prod ilike '%ipaq%4700%' order by plno;
QUERY PLAN
-----------------------------------------------------------------------------------------------------------------------
Sort (cost=226117.81..226118.36 rows=222 width=615) (actual time= 7011 .74.. 7012 .05 rows=494 loops=1)
Sort Key: plno
-> Seq Scan on plprice_00 (cost=0.00..226109.14 rows=222 width=615) (actual time=66.19..7002.57 rows=494 loops=1)
Filter: (prod ~~* '%ipaq%4700%'::text)
Total runtime: 7012.44 msec
(5 rows)
# set enable_seqscan to off;
SET
# explain analyze select * from plprice_00 where prod ilike '%ipaq%4700%' order by plno;
QUERY PLAN
------------------------------------------------------------------------------------------------------------------------------------------
Index Scan using pk_prc_plno_00 on plprice_00 (cost=0.00..332902.24 rows=222 width=615) (actual time= 254 .00.. 16325 .67 rows=494 loops=1)
Filter: (prod ~~* '%ipaq%4700%'::text)
Total runtime: 16326.93 msec
(3 rows)0.25 сек < 7 сек < 16 сек
vfabrа сортировки ... если грамотно оптимизатор запинать то и ордер может не понадобитсядаже если сейчас получилось запинать оптимизатор на нужный план выполнения запроса (допустим по индексу), условие order by, кажущееся теперь ненужным, из текста запроса убирать нельзя. на тот случай, если вдруг когда-нибудь в будущем оптимизатор вздумает выбрать для этого запроса другой план, то у вас запрос замедлится (допустим из-за Sort-а), но не сломается! (результат останентся упорядоченным как требуется) или вы что-то другое имели в виду? :)