Re: Limit + group + join

From: Mark Kirkwood
Subject: Re: Limit + group + join
Date: ,
Msg-id: 430FA5BD.2070407@paradise.net.nz
(view: Whole thread, Raw)
In response to: Re: Limit + group + join  (Tom Lane)
Responses: Re: Limit + group + join  (Tom Lane)
List: pgsql-performance

Tree view

Limit + group + join  (Tobias Brox, )
 Re: Limit + group + join  ("Jeffrey W. Baker", )
  Re: Limit + group + join  (Tobias Brox, )
  Re: Limit + group + join  ("Jeffrey W. Baker", )
 Re: Limit + group + join  (Mark Kirkwood, )
  Re: Limit + group + join  (Tobias Brox, )
  Re: Limit + group + join  (Stephan Szabo, )
  Re: Limit + group + join  (Tom Lane, )
   Re: Limit + group + join  (Mark Kirkwood, )
    Re: Limit + group + join  (Tom Lane, )
   Re: Limit + group + join  (Mark Kirkwood, )
    Re: Limit + group + join  (Tom Lane, )
     Re: Limit + group + join  (Mark Kirkwood, )
      Re: Limit + group + join  (Tobias Brox, )
   Re: Limit + group + join  (Greg Stark, )
 Re: Limit + group + join  ("Merlin Moncure", )
 Re: Limit + group + join  ("Merlin Moncure", )

Tom Lane wrote:
> Mark Kirkwood <> writes:
>
>>What is interesting is why this plan is being rejected...
>
>
> Which PG version are you using exactly?  That mistake looks like an
> artifact of the 8.0 "fuzzy plan cost" patch, which we fixed recently:
> http://archives.postgresql.org/pgsql-committers/2005-07/msg00474.php
>

Right on - 8.0.3 (I might look at how CVS tip handles this, could be
interesting).

> But Tobias wasn't happy with 7.4 either, so I'm not sure that the fuzzy
> cost issue explains his results.
>
> As far as the "desc" point goes, the problem is that mergejoins aren't
> capable of dealing with backward sort order, so a merge plan isn't
> considered for that case (or at least, it would have to have a sort
> after it, which pretty much defeats the point for a fast-start plan).
> I have some ideas about fixing this but it won't happen before 8.2.

That doesn't explain why the nested loop is being kicked tho', or have I
missed something obvious? - it's been known to happen :-)...

Cheers

Mark



pgsql-performance by date:

From: "tobbe"
Date:
Subject: Re: Performance for relative large DB
From: Bruno Wolff III
Date:
Subject: Re: Need indexes on empty tables for good performance ?