Re: index scan with index cond on first column doesn't

From: Stephan Szabo <sszabo(at)megazone23(dot)bigpanda(dot)com>
To: Greg Stark <gsstark(at)mit(dot)edu>
Cc: <pgsql-general(at)postgresql(dot)org>
Subject: Re: index scan with index cond on first column doesn't
Date: 2003-02-13 22:28:40
Message-ID: 20030213141639.I50402-100000@megazone23.bigpanda.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general


On 13 Feb 2003, Greg Stark wrote:

> Stephan Szabo <sszabo(at)megazone23(dot)bigpanda(dot)com> writes:
>
> > On 13 Feb 2003, Greg Stark wrote:
> >
> > > Here's a corner case where the optimizer is doing a redundant sort. I'm not
> > > sure if I'm doing something wrong or if it's just something the optimizer
> > > doesn't notice.
> >
> > I'm guessing that it doesn't realize that in this case the sort is
> > redundant since I think it's only necessarily redundant for = singlevalue
> > with no ors.
>
> I'm not sure. reading the code there does seem to be a special code path for
> ors anyways. This codepath claims to be for non-'or' restriction clauses.

Right, but it's more than just 'or' restrictions. It's any case where the
condition returns more than one value of the first column that causes the
sort to be non-redundant AFAICS. I'm at work so I can't really spend time
going through code, so I don't know if the code you're pointing to only
applies to conditions using equality, but I think greater than, less than,
would be examples where it'd not be redundant.

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Dmitry Tkach 2003-02-13 23:06:55 Re: CREATE TABLE with a name derived from a string
Previous Message Patrick Nelson 2003-02-13 22:22:48 pgtcl way of specifying a user