On 10/4/07, Ben <bench@silentmedia.com> wrote:
> On Thu, 4 Oct 2007, Tom Lane wrote:
>
> > You're being about as clear as mud here, except that you obviously lied
> > about what you were doing in your first message. If you have a planner
> > problem, show us the *exact* query, the *exact* table definition, and
> > unfaked EXPLAIN ANALYZE output.
>
> I didn't realize that simplification was viewed as so sinister, but
> thanks, I'll remember that in the future.

It's not sinister, it's counterproductive and wastes people's time.

---------------------------(end of broadcast)---------------------------
TIP 3: Have you checked our extensive FAQ?

http://www.postgresql.org/docs/faq

Scott Marlowe wrote:
> On 10/4/07, Ben <bench@silentmedia.com> wrote:
>> On Thu, 4 Oct 2007, Tom Lane wrote:
>>
>>> You're being about as clear as mud here, except that you obviously lied
>>> about what you were doing in your first message. If you have a planner
>>> problem, show us the *exact* query, the *exact* table definition, and
>>> unfaked EXPLAIN ANALYZE output.
>> I didn't realize that simplification was viewed as so sinister, but
>> thanks, I'll remember that in the future.
>
> It's not sinister, it's counterproductive and wastes people's time.

Unless "Ben" is an alias for someone high up with an unnamed rival
database, seeking to distract us all... How do you find out the IP
address of a yacht? ;-)

--
Richard Huxton
Archonet Ltd

---------------------------(end of broadcast)---------------------------
TIP 7: You can help support the PostgreSQL project by donating at

http://www.postgresql.org/about/donate

Ben <bench@silentmedia.com> writes:
> On Thu, 4 Oct 2007, Simon Riggs wrote:
> I thought that might explain it, but then I'm surprised that it can still
> use an index when the first two columns of the index aren't in the query.
> Wouldn't that mean that it might have to walk the entire index to find
> matching rows?

> ....unless it's smart enough to realize that the first two columns will
> match everything. Which would be cool.

There's some limited smarts in there about deciding that leading columns
of an index don't matter to the sort ordering if they're constrained to
just one value by the query. But it doesn't catch the case you need,
which is that columns of an ORDER BY request are no-ops when they're
constrained to just one value.

That whole area has been rewritten for 8.3 and I believe it will handle
this case. No time to try it right now though.

regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to majordomo@postgresql.org so that your
message can get through to the mailing list cleanly

On Thu, 4 Oct 2007, Tom Lane wrote:

> There's some limited smarts in there about deciding that leading columns
> of an index don't matter to the sort ordering if they're constrained to
> just one value by the query. But it doesn't catch the case you need,
> which is that columns of an ORDER BY request are no-ops when they're
> constrained to just one value.

Oh, no, that explains it perfectly, because that's precisely the case I
have - I dropped the columns from the ordering, but not the where clause.
Thanks, now I understand the current behavior.

---------------------------(end of broadcast)---------------------------
TIP 2: Don't 'kill -9' the postmaster