On Fri, 2007-01-26 at 10:58 -0500, Tom Lane wrote: > "Simon Riggs" <[EMAIL PROTECTED]> writes: > > If there's clear benefit and a clear way forward, then we might just be > > OK for 8.3. If not, I'll put this back on the shelf again in favour of > > other ideas. > > I think this is still a long way off, and there are probably more useful > things to work on for 8.3. > > Part of my antagonism stems from the fact that by means of the operator > family rewrite I've been getting rid of some longstanding but really > quite unacceptable assumptions about "this operator does that". I don't > want to see us start putting unsupported semantic assumptions back into > the optimizer; rather its assumptions about operator behavior need to be > clearly specified. As an example, without some careful preliminary > thinking I'd have probably folded all the numeric types into one big > opfamily and thereby broken transitivity :-(, leading to bugs that would > be devilish to figure out.
OK, no problems. All of the above says "time", which is becoming rare as we approach 8.3 anyways. I'll pick it up again in 8.4. Some notes-to-self for the future: - ideally want to be able to decide transformability at CREATE INDEX time; this will reduce planning time for functional index usage when there is no possible transforms. - may want to do this by having a special catalog table that holds the cases that *will* work, to make it both safer and faster to look up. Sort of like pg_autovacuum -> absence means No. -- Simon Riggs EnterpriseDB http://www.enterprisedb.com ---------------------------(end of broadcast)--------------------------- TIP 6: explain analyze is your friend
