Re: Feature request: smarter use of conditional indexes

From: Christopher Kings-Lynne <chriskl(at)familyhealth(dot)com(dot)au>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: John Siracusa <siracusa(at)mindspring(dot)com>, Postgres Performance <pgsql-performance(at)postgresql(dot)org>
Subject: Re: Feature request: smarter use of conditional indexes
Date: 2004-03-04 01:31:48
Message-ID: 40468704.9030601@familyhealth.com.au
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance


>>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 ;-)
>
> The routine you want to teach about this is pred_test_simple_clause() in
> src/backend/optimizer/path/indxpath.c. ISTM that it's legitimate to
> conclude that "foo IS NOT NULL" is implied by "foo op anything" or
> "anything op foo" if the operator is marked strict.

I've actually mentioned this one before in that of all the partial
indexes I have, almost all of then are a WHERE x IS NOT NULL format. I
don't know if that's a common use, but if it is, then maybe it's worth
just adding the knowledge for IS NOT NULL...

The other thing is that at the moment, cascading foreign keys will not
use partial indexes even if they match the predicate. Maybe an IS NOT
NULL hack will help there...

Chris

In response to

Browse pgsql-performance by date

  From Date Subject
Next Message Florian Weimer 2004-03-04 10:06:08 Re: Bulk INSERT performance in 7.4.1
Previous Message Paul Thomas 2004-03-04 00:52:08 Re: Scaling further up