Re: Feature request: smarter use of conditional indexes
On 3/3/04 6:53 PM, Tom Lane wrote:
John Siracusa <siracusa@mindspring.com> writes:
Given an index like this:
CREATE UNIQUE INDEX i1 ON t1 (c1) WHERE c1 IS NOT NULL;
and a query like this:
SELECT * FROM t1 WHERE c1 = 123;
I'd like the planner to be smart enough to use an index scan using
i1.Send a patch ;-)
How does this look? It seems to do what I want without horribly
breaking anything as far as I can tell. I ran "make check" and got the
same result as I did before my changes (5 failures in OS X 10.3.2).
But then, I also got the same result when I wasn't even checking to
make sure that both clauses were looking at the same variable :) I'm
not sure how to add a test for this particular change either.
% cvs diff src/backend/optimizer/path/indxpath.c
Index: src/backend/optimizer/path/indxpath.c
===================================================================
RCS file:
/projects/cvsroot/pgsql-server/src/backend/optimizer/path/indxpath.c,v
retrieving revision 1.156
diff -r1.156 indxpath.c
1032a1033,1055{
/* One last chance: "var = const" or "const = var" implies "var is
not null" */
if (IsA(predicate, NullTest) &&
((NullTest *) predicate)->nulltesttype == IS_NOT_NULL &&
is_opclause(clause) && op_strict(((OpExpr *) clause)->opno) &&
length(((OpExpr *) clause)->args) == 2)
{
leftop = get_leftop((Expr *) clause);
rightop = get_rightop((Expr *) clause);/* One of the two arguments must be a constant */
if (IsA(rightop, Const))
clause_var = leftop;
else if (IsA(leftop, Const))
clause_var = rightop;
else
return false;/* Finally, make sure "var" is the same var in both clauses */
if (equal(((NullTest *) predicate)->arg, clause_var))
return true;
}
1033a1057
Show quoted text
}
--On Saturday, March 06, 2004 21:29:27 -0500 John Siracusa
<siracusa@mindspring.com> wrote:
On 3/3/04 6:53 PM, Tom Lane wrote:
John Siracusa <siracusa@mindspring.com> writes:
Given an index like this:
CREATE UNIQUE INDEX i1 ON t1 (c1) WHERE c1 IS NOT NULL;
and a query like this:
SELECT * FROM t1 WHERE c1 = 123;
I'd like the planner to be smart enough to use an index scan using
i1.Send a patch ;-)
Just a suggestion, please use diff -c format, as it makes it easier for
the folks who apply the patches to do so.
[snip]
--
Larry Rosenman http://www.lerctr.org/~ler
Phone: +1 972-414-9812 E-Mail: ler@lerctr.org
US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749
Larry Rosenman <ler@lerctr.org> writes:
Just a suggestion, please use diff -c format, as it makes it easier for
the folks who apply the patches to do so.
That's not just a suggestion ... patches that aren't in diff -c (or at
least diff -u) format will be rejected out of hand. Without the context
lines provided by these formats, applying a patch is an exercise in
risk-taking, because you can't be certain that you are applying the same
patch the submitter intended.
Personally I consider -c format the only one of the three that is
readable for reviewing purposes, so even if I weren't intending
immediate application, I'd ask for -c before looking at the patch.
There are some folks who consider -u format readable, but I'm not
one of them ...
BTW, patches really ought to go to pgsql-patches ... they're a bit
off-topic here.
regards, tom lane
Tom Lane wrote:
Larry Rosenman <ler@lerctr.org> writes:
Just a suggestion, please use diff -c format, as it makes it easier for
the folks who apply the patches to do so.That's not just a suggestion ... patches that aren't in diff -c (or at
least diff -u) format will be rejected out of hand. Without the context
lines provided by these formats, applying a patch is an exercise in
risk-taking, because you can't be certain that you are applying the same
patch the submitter intended.
Also, when you get 'fuzz' output when applying the patch, you should
review the patch to make sure it appeared in the right place. That has
gotten me a few times.
--
Bruce Momjian | http://candle.pha.pa.us
pgman@candle.pha.pa.us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073
On Sunday 07 March 2004 09:16, Tom Lane wrote:
Personally I consider -c format the only one of the three that is
readable for reviewing purposes, so even if I weren't intending
immediate application, I'd ask for -c before looking at the patch.
There are some folks who consider -u format readable, but I'm not
one of them ...
I was wondering what people use to keep track of their personal development
especially when they do not have a cvs commit access.
I am toying with idea of using GNU arch for personal use. It encourages
branching, merging and having as many repository trees as possible. I haven't
tried it in field as yet but if it delivers what it promises, it could be a
great assistance.
I know that there are not many postgresql branches like say linux kernel needs
but having a good tool does not hurt, isn't it..:-)
Just a thought..
Shridhar
Shridhar Daithankar wrote:
On Sunday 07 March 2004 09:16, Tom Lane wrote:
Personally I consider -c format the only one of the three that is
readable for reviewing purposes, so even if I weren't intending
immediate application, I'd ask for -c before looking at the patch.
There are some folks who consider -u format readable, but I'm not
one of them ...I was wondering what people use to keep track of their personal development
especially when they do not have a cvs commit access.
See the developer's FAQ. They usually use cporig to make copies of
files they are going to modify, then difforig to send the diffs to us,
or they copy the entire source tree, modify it, and do a recursive diff
themselves.
--
Bruce Momjian | http://candle.pha.pa.us
pgman@candle.pha.pa.us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073
Bruce Momjian wrote:
Shridhar Daithankar wrote:
I was wondering what people use to keep track of their personal development
especially when they do not have a cvs commit access.See the developer's FAQ. They usually use cporig to make copies of
files they are going to modify, then difforig to send the diffs to us,
or they copy the entire source tree, modify it, and do a recursive diff
themselves.
I used to use cvsup to get a full copy of the repository, and then work
locally out of that (check out and diff only).
Joe