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.
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 |