Re: [HACKERS] Index scan?

From: Bruce Momjian <maillist(at)candle(dot)pha(dot)pa(dot)us>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Theo Kramer <theo(at)flame(dot)co(dot)za>, hackers(at)postgreSQL(dot)org
Subject: Re: [HACKERS] Index scan?
Date: 1999-08-13 16:54:30
Message-ID: 199908131654.MAA08547@candle.pha.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

> 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.

Added to TODO:

* Allow optimizer to prefer plans that match ORDER BY

--
Bruce Momjian | http://www.op.net/~candle
maillist(at)candle(dot)pha(dot)pa(dot)us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Bruce Momjian 1999-08-13 17:03:43 Re: [HACKERS] Single row fetch from backend
Previous Message Vince Vielhaber 1999-08-13 15:52:45 Re: We won!