Tobias wrote:
> Splendid :-) Unfortunately we will not be upgrading for some monthes
> still,
> but anyway I'm happy. This provides yet another good argument for
> upgrading
> sooner. I'm also happy to see such a perfect match:
>
> - A problem that can be reduced from beeing complex and
>pr
[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
Tom Lane <[EMAIL PROTECTED]> writes:
> 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
Interestingly enough, 7.4.8 and 8.1devel-2005-08-23 all behave the same
as 8.0.3 for me (tables freshly ANALYZEd):
joinlimit=# SELECT version();
version
---
Mark Kirkwood <[EMAIL PROTECTED]> writes:
> That doesn't explain why the nested loop is being kicked tho',
No, but I think the fuzzy-cost bug does. There are two different issues
here.
regards, tom lane
---(end of broadcast)---
Tom Lane wrote:
Mark Kirkwood <[EMAIL PROTECTED]> 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-c
Mark Kirkwood <[EMAIL PROTECTED]> 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/ms
Mark Kirkwood
> > The 'desc' seems to be the guy triggering the sort, e.g:
>
> Oh; really an accident that I didn't notice myself, I was actually
going
> to
> remove all instances of "desc" in my simplification, but seems like I
> forgot.
If desc is the problem you can push the query into a subqu
On Fri, 26 Aug 2005, Mark Kirkwood wrote:
> However being a bit brutal:
>
> set enable_mergejoin=false;
> set enable_hashjoin=false;
>
> explain select c.id from c join b on c_id=c.id group by c.id order by
> c.id desc limit 5;
> QUERY PLAN
>
> ---
[Mark Kirkwood - Fri at 03:01:01PM +1200]
> Tobias,
> Interesting example:
>
> The 'desc' seems to be the guy triggering the sort, e.g:
Oh; really an accident that I didn't notice myself, I was actually going to
remove all instances of "desc" in my simplification, but seems like I forgot.
> Howe
Tobias,
Interesting example:
The 'desc' seems to be the guy triggering the sort, e.g:
explain select c.id from c join b on c_id=c.id group by c.id order by
c.id limit 5;
QUERY PLAN
---
On Thu, 2005-08-25 at 18:56 -0700, Jeffrey W. Baker wrote:
> On Fri, 2005-08-26 at 02:27 +0200, Tobias Brox wrote:
> > Consider this setup - which is a gross simplification of parts of our
> > production system ;-)
> >
> > create table c (id integer primary key);
> > create table b (id integer
[Jeffrey W. Baker - Thu at 06:56:59PM -0700]
> > explain select c.id from c join b on c_id=c.id group by c.id order by c.id
> > desc limit 5;
>
> Where's b in this join clause?
"join b on c_id=c.id"
It just a funny way of writing:
select c.id from c,b where c_id=c.id group by c.id order by c.
On Fri, 2005-08-26 at 02:27 +0200, Tobias Brox wrote:
> Consider this setup - which is a gross simplification of parts of our
> production system ;-)
>
> create table c (id integer primary key);
> create table b (id integer primary key, c_id integer);
> create index b_on_c on b(c_id)
>
>
16 matches
Mail list logo
