Re: BUG #1393: Adding 'LIMIT 1' to the query halts forever

From: Michael Fuhr <mike(at)fuhr(dot)org>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: "Fahad G(dot)" <Fahad(dot)Gilani(at)anusf(dot)anu(dot)edu(dot)au>, pgsql-bugs(at)postgresql(dot)org
Subject: Re: BUG #1393: Adding 'LIMIT 1' to the query halts forever
Date: 2005-01-17 02:56:49
Message-ID: 20050117025649.GB83758@winnie.fuhr.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

On Sun, Jan 16, 2005 at 04:08:35PM -0500, Tom Lane wrote:
> Michael Fuhr <mike(at)fuhr(dot)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/

In response to

Browse pgsql-bugs by date

  From Date Subject
Next Message Daniel Ceregatti 2005-01-17 03:08:22 Re: Error in 8.0 rc5 with repeat calls to array operator
Previous Message Tom Lane 2005-01-17 02:35:05 Re: Error in 8.0 rc5 with repeat calls to array operator