From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | "Christopher Kings-Lynne" <chriskl(at)familyhealth(dot)com(dot)au> |
Cc: | "Dave Page" <dpage(at)vale-housing(dot)co(dot)uk>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Partial index on date column |
Date: | 2003-03-07 05:39:09 |
Message-ID: | 27982.1047015549@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
"Christopher Kings-Lynne" <chriskl(at)familyhealth(dot)com(dot)au> writes:
>> Partial-index condition matching is a horribly difficult problem in
>> general, and we only attempt a few limited cases right now.
> Is it worth hard-coding in the IS NOT NULL case?
Damifino. I have no fundamental objection to doing so --- but I'd want
to see some sort of cost-benefit argument showing that it wouldn't be
a net loss on average. It's real easy to blow a few cycles on every
query looking for cases that don't show up often enough to justify the
distributed cost :-(.
It helps a lot if you can put in short-circuits that prevent the
matching work from being done on simple queries. For example, the
parser/rewriter/planner take care to keep track of whether a query
contains any sub-SELECTs, and if you look in the planner you will notice
quite a lot of work that gets short-circuited when there aren't any.
I'm not sure how to make a short-circuit test for this case, however.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Christopher Kings-Lynne | 2003-03-07 05:48:53 | Re: Brain dump: btree collapsing |
Previous Message | Bruce Momjian | 2003-03-07 05:36:21 | Re: Brain dump: btree collapsing |