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 |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
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.
From | Date | Subject | |
---|---|---|---|
Next Message | Jim C. Nasby | 2006-03-28 17:26:35 | Re: count(*) performance |
Previous Message | Marcos | 2006-03-28 16:55:28 | Re: Decide between Postgresql and Mysql (help of |