From: Dave Dutcher <dave@tridecap.com>
To: 'Steinar H. Gunderson' <sgunderson@bigfoot.com>
To: pgsql-performance@postgresql.org
Subject: Re: simple join uses indexes, very slow
Date: Tue, 28 Mar 2006 11:20:19 -0600
Message-ID: <00da01c6528b$e3b6fd30$8300a8c0@tridecap.com> (raw)
In-Reply-To: <20060328162908.GB26539@uio.no>
> -----Original Message-----
> From: pgsql-performance-owner@postgresql.org
[mailto:pgsql-performance-
> owner@postgresql.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.
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-performance@postgresql.org
Cc: dave@tridecap.com, sgunderson@bigfoot.com
Subject: Re: simple join uses indexes, very slow
In-Reply-To: <00da01c6528b$e3b6fd30$8300a8c0@tridecap.com>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox