| From: | Hannu Krosing <hannu(at)tm(dot)ee> |
|---|---|
| To: | Don Baccus <dhogaza(at)pacifier(dot)com> |
| Cc: | chris(at)bitmead(dot)com, pgsql-hackers(at)postgreSQL(dot)org |
| Subject: | Re: [HACKERS] Solution for LIMIT cost estimation |
| Date: | 2000-02-15 00:43:45 |
| Message-ID: | 38A8A141.DDDE8548@tm.ee |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | 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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Hannu Krosing | 2000-02-15 00:52:25 | Re: [HACKERS] Solution for LIMIT cost estimation |
| Previous Message | Chris Bitmead | 2000-02-14 23:30:17 | Re: [HACKERS] Solution for LIMIT cost estimation |