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: | Raw Message | Whole Thread | 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 |