Re: Strange logic for partial index proving

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: "Jim C(dot) Nasby" <decibel(at)decibel(dot)org>
Cc: Simon Riggs <simon(at)2ndquadrant(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Strange logic for partial index proving
Date: 2005-06-21 22:49:14
Message-ID: 20787.1119394154@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

"Jim C. Nasby" <decibel(at)decibel(dot)org> writes:
> Has anyone looked at how hard it would be to identify impossible
> conditions as part of planning the query?

The question in my mind is not so much how hard it would be as how many
cycles we would waste trying to prove things that won't be true for
99.999% of queries. There is always a tradeoff involved when you add
more processing to the planner, and in this case I can't believe that it
would be a win.

Simon is looking at a different and much more constrained case (WHERE
clause provably inconsistent with check constraints of individual tables
in an inheritance hierarchy), and so the risk of wasted processing
doesn't loom so large.

Note also that when the contradictory constraints are on a column of a
btree index, the amount you save by recognizing the condition in the
planner isn't all that great, since the btree index code discovers it
during plan startup anyway.

regards, tom lane

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Alvaro Herrera 2005-06-21 23:18:09 Re: Why is checkpoint so costly?
Previous Message Tom Lane 2005-06-21 22:42:53 The contrib hit list