Re: [HACKERS] Solution for LIMIT cost estimation
От | Hannu Krosing |
---|---|
Тема | Re: [HACKERS] Solution for LIMIT cost estimation |
Дата | |
Msg-id | 38A8A141.DDDE8548@tm.ee обсуждение исходный текст |
Ответ на | Solution for LIMIT cost estimation (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: [HACKERS] Solution for LIMIT cost estimation
|
Список | pgsql-hackers |
Don Baccus wrote: > > At 11:41 AM 2/14/00 +0200, Hannu Krosing wrote:>Maybe we should still discourage the use of LIMIT, and rather introduce > >another "mode" for optimiser, activated by SET FastStart TO 'ON'. > >Then queries with limit could be rewritten into > >SET FastStart to 'ON'; > >DECLARE > >MOVE > >FETCH > >CLOSE > >SET FastStart to PREVIOUS_VALUE; > > > >also maybe we will need PUSH/POP for set commands ? > > Well...personally I don't see LIMIT as being particularly harmful, > and it is a convenience. Remember, for the web space you're speaking > of keeping overhead low is a real concern, and requiring a series > of queries where currently only one needed will probably go over like > a lead ballon. I meant that the _backend_ could (in some distant future, when the optimiser is perfect :) implement LIMIT as above sequence. --------------- Hannu
В списке pgsql-hackers по дате отправления: