[Tom Lane]
> I looked into this and (...) I've committed some changes that hopefully will
> let 8.1 be smarter about GROUP BY ... LIMIT queries.
[Mark Kirkwood]
> Very nice :-)
(...)
> This is 8.1devel from today.
Splendid :-) Unfortunately we will not be upgrading for some monthes still,
but any
Tom Lane wrote:
I looked into this and found that indeed the desirable join plan was
getting generated, but it wasn't picked because query_planner didn't
have an accurate idea of how much of the join needed to be scanned to
satisfy the GROUP BY step. I've committed some changes that hopefully
w
Mark Kirkwood <[EMAIL PROTECTED]> writes:
> joinlimit=# EXPLAIN SELECT c.id FROM c JOIN b ON c_id=c.id GROUP BY
> c.id ORDER BY c.id DESC LIMIT 5;
> [ fails to pick an available index-scan-backward plan ]
I looked into this and found that indeed the desirable join plan was
getting generated, but
"Steinar H. Gunderson" <[EMAIL PROTECTED]> writes:
> On Fri, Aug 26, 2005 at 07:31:51PM -0400, Tom Lane wrote:
>> Or you could just play with the order of the filter conditions ... for
>> example, the date condition at the end is probably far cheaper to test
>> than the text comparisons, so if that
"Steinar H. Gunderson" <[EMAIL PROTECTED]> writes:
> On Sat, Aug 27, 2005 at 11:05:01AM -0400, Tom Lane wrote:
>> It could, but it doesn't really have enough information. We don't
>> currently have any model that some operators are more expensive than
>> others. IIRC the only sort of reordering t
On Sat, Aug 27, 2005 at 11:05:01AM -0400, Tom Lane wrote:
> It could, but it doesn't really have enough information. We don't
> currently have any model that some operators are more expensive than
> others. IIRC the only sort of reordering the current code will do
> in a filter condition list is
At 10:27 AM 8/27/2005, Tom Lane wrote:
Arjen van der Meijden <[EMAIL PROTECTED]> writes:
> But appareantly there is a bug in the explain mechanism of the 8.1devel
> I'm using (I downloaded a nightly 25 august somewhere in the morning
> (CEST)), since it returned:
> ERROR: bogus varno: 9
Yeah, s
Arjen van der Meijden <[EMAIL PROTECTED]> writes:
> But appareantly there is a bug in the explain mechanism of the 8.1devel
> I'm using (I downloaded a nightly 25 august somewhere in the morning
> (CEST)), since it returned:
> ERROR: bogus varno: 9
Yeah, someone else sent in a test case for thi
On 27-8-2005 0:56, Tom Lane wrote:
Arjen van der Meijden <[EMAIL PROTECTED]> writes:
As said, it chooses sequential scans or "the wrong index plans" over a
perfectly good plan that is just not selected when the parameters are
"too well tuned" or sequential scanning of the table is allowed.
On Fri, Aug 26, 2005 at 07:31:51PM -0400, Tom Lane wrote:
> Or you could just play with the order of the filter conditions ... for
> example, the date condition at the end is probably far cheaper to test
> than the text comparisons, so if that's fairly selective it'd be worth
> putting it first.
T
On Cum, 2005-08-26 at 19:31 -0400, Tom Lane wrote:
> I think the problem is that the planner is underestimating the cost of
> evaluating this complicated filter condition:
>
> > -> Seq Scan on scf_irsaliye irs (cost=0.00..30.00 rows=1
> > width=20) (actual time=0.290..0.290 rows
11 matches
Mail list logo
