Thread: indxpath.c refactoring
This simple refactoring patch moves all of the code associated with Partial Index planning into a single file. This isolates it from other code changes that may take place over the next few months, as well as setting the scene for a number of changes that will hopefully take place with that code. This should allow work to continue on this undisturbed; more work will happen within the 8.1 window, so please approve this patch to cvstip now. Changes likely on this code are - redesigning the low level routines to allow them to perform their stuff for both Partial Index and Constraint-based elimination (aka Partitioning...) - allowing equivalence class re-write - allow handling for r-tree operators - maybe GIST also?? Better to do this change now, than try to do it when code gets more complex. - Passes make check on current cvstip. - No functional code changes of any kind, just moving between modules. Changes: - code removal from indxpath.c - code addition to new module predtest.c - no changes required to header files - update Makefile Best Regards, Simon Riggs
Attachment
Simon Riggs <simon@2ndquadrant.com> writes:
> This simple refactoring patch moves all of the code associated with
> Partial Index planning into a single file.
Applied with some revisions -
* I put the new predtest.c file into optimizer/util, which seemed a more
plausible location than /path, and gave it its own header file.
* I thought check_partial_indexes() should stay in indxpath.c; it is an
application of the theorem-proving module to indexes, not part of the
prover proper.
* I took the opportunity to rename pred_test() to predicate_implied_by(),
which seems more clear about what it's doing and in which direction.
As for the future...
> - redesigning the low level routines to allow them to perform their
> stuff for both Partial Index and Constraint-based elimination (aka
> Partitioning...)
The other main entry point should probably be called something like
predicate_refuted_by?
> - allow handling for r-tree operators
I don't see anyone very excited about r-tree these days; have you
noticed that no one has stepped up to repair the known semantic errors?
I wouldn't spend any time on it in the prover.
> - maybe GIST also??
The trouble with GiST is that the logical structure of each opclass
could be completely different from the next --- it's certainly not
possible to have a simple fixed table of implications. Again, we have
much more important fish to fry, anyway ...
regards, tom lane
> I don't see anyone very excited about r-tree these days; have you > noticed that no one has stepped up to repair the known semantic errors? > I wouldn't spend any time on it in the prover. That sort of thing is always self-fulfilling. If rtrees were fast, logged and rad, then more people would use them :) Chris
Christopher Kings-Lynne <chriskl@familyhealth.com.au> writes:
>> I don't see anyone very excited about r-tree these days; have you
>> noticed that no one has stepped up to repair the known semantic errors?
>> I wouldn't spend any time on it in the prover.
> That sort of thing is always self-fulfilling. If rtrees were fast,
> logged and rad, then more people would use them :)
The prophecy I'd like to see become self-fulfilling is that we get GIST
to production quality and then r-trees wither on the vine because
there's no reason to use them. I'm not aware of any reason to prefer
r-tree to an equivalent GIST opclass...
regards, tom lane
On Fri, 2005-06-10 at 18:33 -0400, Tom Lane wrote: > Simon Riggs <simon@2ndquadrant.com> writes: > > This simple refactoring patch moves all of the code associated with > > Partial Index planning into a single file. > > Applied with some revisions - > > * I put the new predtest.c file into optimizer/util, which seemed a more > plausible location than /path, and gave it its own header file. > > * I thought check_partial_indexes() should stay in indxpath.c; it is an > application of the theorem-proving module to indexes, not part of the > prover proper. > > * I took the opportunity to rename pred_test() to predicate_implied_by(), > which seems more clear about what it's doing and in which direction. > Many thanks. > As for the future... > > > - redesigning the low level routines to allow them to perform their > > stuff for both Partial Index and Constraint-based elimination (aka > > Partitioning...) > > The other main entry point should probably be called something like > predicate_refuted_by? Will do. Best Regards, Simon Riggs