| From: | Theo Kramer <theo(at)flame(dot)co(dot)za> |
|---|---|
| To: | hackers(at)postgreSQL(dot)org |
| Subject: | Re: [HACKERS] Index scan? |
| Date: | 1999-08-13 15:29:21 |
| Message-ID: | 37B439D1.A6936FE8@flame.co.za |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Tom Lane wrote:
> Yeah, this is a known limitation of the planner: it's only bright enough
> to skip an explicit sort step for an ORDER BY clause when the plan that
> *would be chosen anyway in the absence of ORDER BY* happens to produce
> a properly sorted result. In your first example the WHERE clause can
> be exploited to scan only part of the index (notice the difference in
> estimated output row counts), so an indexscan gets chosen --- and that
> just happens to deliver the sorted result you want. In the second
> example the plan-picker sees no reason to use anything more expensive
> than a sequential scan :-(
>
> We need to push awareness of the output ordering requirement down into
> the code that chooses the basic plan. It's on the TODO list (or should
> be) but I dunno when someone will get around to it.
I can't wait :-)
--------
Regards
Theo
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Theo Kramer | 1999-08-13 15:33:28 | Re: [HACKERS] Single row fetch from backend |
| Previous Message | Theo Kramer | 1999-08-13 15:28:30 | Re: [HACKERS] COPY |