Skip site navigation (1) Skip section navigation (2)

Re: simple join uses indexes, very slow

From: "Dave Dutcher" <dave(at)tridecap(dot)com>
To: "'Steinar H(dot) Gunderson'" <sgunderson(at)bigfoot(dot)com>,<pgsql-performance(at)postgresql(dot)org>
Subject: Re: simple join uses indexes, very slow
Date: 2006-03-28 17:20:19
Message-ID: 00da01c6528b$e3b6fd30$8300a8c0@tridecap.com (view raw or flat)
Thread:
Lists: pgsql-performance
> -----Original Message-----
> From: pgsql-performance-owner(at)postgresql(dot)org
[mailto:pgsql-performance-
> owner(at)postgresql(dot)org] On Behalf Of Steinar H. Gunderson
> Sent: Tuesday, March 28, 2006 10:29 AM
> 
> An index on (A,B,C) can be used for a query on (A,B) or (A), so it
doesn't
> really matter. It isn't usable for a query on (B), (C) or (B,C),
though.
> (The
> index rows will get bigger, of course, so you'll need more I/O if you
want
> to
> scan large parts of it, but I guess that's beside the point.)


I guess what I am really curious about is why was the OP getting an
expensive sort when the planner tried a merge join?  Most of the time
was spent sorting the parameters parameters table by opset_num even
though opset_num is indexed.  Isn't Postgres able to walk the index
instead of sorting?  I was wondering if maybe Postgres wasn't
recognizing that it could just walk the index because the opset_num
column isn't the first in the index.





In response to

Responses

pgsql-performance by date

Next:From: Jim C. NasbyDate: 2006-03-28 17:26:35
Subject: Re: count(*) performance
Previous:From: MarcosDate: 2006-03-28 16:55:28
Subject: Re: Decide between Postgresql and Mysql (help of

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group