Re: BUG #1393: Adding 'LIMIT 1' to the query halts forever - Mailing list pgsql-bugs

From Michael Fuhr
Subject Re: BUG #1393: Adding 'LIMIT 1' to the query halts forever
Date
Msg-id 20050117025649.GB83758@winnie.fuhr.org
Whole thread Raw
In response to Re: BUG #1393: Adding 'LIMIT 1' to the query halts forever  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-bugs
On Sun, Jan 16, 2005 at 04:08:35PM -0500, Tom Lane wrote:
> Michael Fuhr <mike@fuhr.org> writes:
>
> > Is taking the downside into consideration a tough problem to solve, or
> > is it simply not worthwhile in the large?
>
> I don't know how to solve it, and whether it would be worthwhile would
> depend considerably on how expensive the proposed solution is ...

Would the topic merit discussion in pgsql-hackers after the dust
from the 8.0 release settles down?  I know little of the theory
behind query planning; I'd hate to waste the developers' time on a
topic that's already been debated or that has little merit.

If the topic is worthwhile, then I was thinking of a configuration
setting that would allow the user to request either "the plan most
likely to be the fastest" or "the plan least likely to be the slowest,"
or maybe something in between.

--
Michael Fuhr
http://www.fuhr.org/~mfuhr/

pgsql-bugs by date:

Previous
From: Tom Lane
Date:
Subject: Re: Error in 8.0 rc5 with repeat calls to array operator
Next
From: "manikanti sreedhar reddy"
Date:
Subject: BUG #1406: subsequent WHEN/ELSE is getting validated, eventhough prior WHEN condition is true