From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Philip Warner <pjw(at)rhyme(dot)com(dot)au> |
Cc: | chris(at)bitmead(dot)com, pgsql-hackers(at)postgreSQL(dot)org |
Subject: | Re: [HACKERS] Solution for LIMIT cost estimation |
Date: | 2000-02-11 06:17:40 |
Message-ID: | 18640.950249860@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Philip Warner <pjw(at)rhyme(dot)com(dot)au> writes:
> Another option is to do what Dec/Rdb does, and allow either optimizer hints
> in a saved plan, or via modified SQL (less portable):
> select * from foo limit 1 row optimize for fast first;
The former is not going to happen in time for 7.0, and the latter is
not entirely palatable --- we are trying to become more SQL-spec-
compliant, not less...
> I also have a question: does the optimizer know about relevant indexes when
> it is trying to return an ordered result set? If not, then 'fast first'
> retrieval may be substantially improved by including such knowledge.
It does know about indexes. The problem is that it is making planning
choices on the basis of cost to retrieve the entire ordered result set,
which leads to pessimal planning when you don't really want any such
thing.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Don Baccus | 2000-02-11 06:35:24 | Re: [HACKERS] Solution for LIMIT cost estimation |
Previous Message | Chris Bitmead | 2000-02-11 06:15:23 | Re: [HACKERS] Solution for LIMIT cost estimation |