Re: Partial index on date column

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

In response to

Browse pgsql-hackers by date

  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