Thread: Inherited indexes.
Hi. To allow indexes to be inherited so unique, foreign keys and such works properly with inheritance has been on the todo for quite some time. I thought that most probably it is a very non trivial thing, perhaps completely rethinking how indexes are done. Or perhaps it is not a feature that is requested allot and therefor no one ever got around to it. I am optimistic so I hoped for the second alternative and begun browsing the sources to see what could be done. Well, from what I have been able to figure out it is not trivial, at least not to me. To be honest I have not completely figured out how the existing indexes works and fit into the constraints. I am not quite sure what I am asking for, quite allot I guess. Is there someone already working on it? If so or if someone is considering perhaps I should start with one of the tasks clearly marked as easy, as an novice to postgresql hacking might be of better use then. Or maybe it is quite easy with the right directions, as in; non complex but takes time. So some one who knows what needs to be done, but do not have the time themselves could give an outline? regards -- //Fredrik Olsson Treyst AB +46-19-362182 fredrik.olsson@treyst.se
Fredrik Olsson <fredrik.olsson@treyst.se> writes: > To allow indexes to be inherited so unique, foreign keys and such works > properly with inheritance has been on the todo for quite some time. I > thought that most probably it is a very non trivial thing, perhaps > completely rethinking how indexes are done. Yup, you're right. There are a couple of major problems, to my mind: 1. A cross-table index would need to store a table OID as well as the existing block/offset information in order to tell you what an entry is pointing at. An extra 4 bytes per index entry (8 bytes if MAXALIGN is 8) is a lot of overhead, so you'd not want to pay that all the time. Which means two index tuple header formats to support, which looks painful. How can that be handled cleanly and efficiently? 2. Nobody has any idea how to handle the locking requirements. For the most part, we assume that a lock on a table protects its associated indexes too. What happens when an index is shared by multiple tables? Are there deadlock problems? A particularly nasty example is that in a unique index, inserting into one table may require visiting other tables (that you've not even got lock on) to see if potentially conflicting rows are still live. > Or perhaps it is not a feature that is requested allot and therefor no > one ever got around to it. No, it's been requested plenty, but it looks hard. See the pghackers archives for previous discussions. regards, tom lane
On Sun, Oct 02, 2005 at 09:46:07PM -0400, Tom Lane wrote: > Fredrik Olsson <fredrik.olsson@treyst.se> writes: > > To allow indexes to be inherited so unique, foreign keys and such works > > properly with inheritance has been on the todo for quite some time. I > > thought that most probably it is a very non trivial thing, perhaps > > completely rethinking how indexes are done. > > Yup, you're right. There are a couple of major problems, to my mind: > > 1. A cross-table index would need to store a table OID as well as the > existing block/offset information in order to tell you what an entry is > pointing at. An extra 4 bytes per index entry (8 bytes if MAXALIGN is > 8) is a lot of overhead, so you'd not want to pay that all the time. > Which means two index tuple header formats to support, which looks > painful. How can that be handled cleanly and efficiently? Wouldn't it make more sense to use a smaller pointer to a table of OIDs that that index covers? I don't know off-hand how much padding there currently is in index tuples, but hopefully this would allow bringing the space usage under control for common cases involving less than a few dozen tables. Another possibility is optimizing for the special case of indexing on a partitioning key. In this case, index values would be very localized to one table, so just storing the table info on each index page (or something similar) would work well. -- Jim C. Nasby, Sr. Engineering Consultant jnasby@pervasive.com Pervasive Software http://pervasive.com work: 512-231-6117 vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461
"Jim C. Nasby" <jnasby@pervasive.com> writes: > On Sun, Oct 02, 2005 at 09:46:07PM -0400, Tom Lane wrote: >> 1. A cross-table index would need to store a table OID as well as the >> existing block/offset information in order to tell you what an entry is >> pointing at. > Wouldn't it make more sense to use a smaller pointer to a table of OIDs > that that index covers? Smaller than what? Don't tell me you want to restrict how many tables a cross-table index can handle :-( In any case, the gain from doing that would be exactly zero because of alignment considerations: the size of an index tuple header really has to be a multiple of MAXALIGN. regards, tom lane
> Another possibility is optimizing for the special case of > indexing on a partitioning key. In this case, index values > would be very localized to one table, so just storing the > table info on each index page (or something similar) would work well. If you have the partitioning key in the index and the partitions don't overlap, it is better to create separate [unique] indexes on the subtables. Building separate indexes per partition is usually preferred because of: 1. performance of dropping a partition 2. smaller index for CE Only if you need an "order by" without a sort step, that spawns more than one partition things usually get ugly. Imho the best solution would be a merge node, that merges results of several index accesses to avoid a sort and still use separate indexes. Such a merge node could probably also detect the case where accessing partitions in a certain order still produces ordered results. Usually you will only want the "one big unique index" when the partitioning is not reflectable in the index keys, and then (also in other db's) such an index is usually a pain ... Andreas
On Tue, Oct 04, 2005 at 11:05:49AM -0400, Tom Lane wrote: > "Jim C. Nasby" <jnasby@pervasive.com> writes: > > On Sun, Oct 02, 2005 at 09:46:07PM -0400, Tom Lane wrote: > >> 1. A cross-table index would need to store a table OID as well as the > >> existing block/offset information in order to tell you what an entry is > >> pointing at. > > > Wouldn't it make more sense to use a smaller pointer to a table of OIDs > > that that index covers? > > Smaller than what? Don't tell me you want to restrict how many tables a > cross-table index can handle :-( > > In any case, the gain from doing that would be exactly zero because of > alignment considerations: the size of an index tuple header really has > to be a multiple of MAXALIGN. Hrm, I see that IndexTupleData doesn't have room 'left over' like HeapTupleData does. If it did, it would probably be a win to allow for indexes that are on less than X number of tables, where X is whatever value we can fit into the tuple header. Since this could be exceeded at any time, we'd also need a flag to indicate that a given tuple is for a table that's not in the lookup table and that an actual OID is stored. Given that that's not (currently) the case, it seems that the unused bit could be used to indicate if the tuple was for a table other than the one the index was originally created on. That would allow for adding a table to an existing index without re-writing the entire thing. It could also provide some speed improvement in cases where the table the index was defined on contained the majority of the data, but that's a pretty far-out corner case. Of course, this is all academic performance tuning until we actually have cross-table indexes. Does that 'just' leave locking as the issue? I think cross-table indexes are going to become a lot more important as our partitioning support increases, so it would be good if this could get done for 8.2 (I think it's on Simon's list right now). -- Jim C. Nasby, Sr. Engineering Consultant jnasby@pervasive.com Pervasive Software http://pervasive.com work: 512-231-6117 vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461
Well, I never said unique, but you're correct, it's pretty undesirable to put a global index on your partitioning key. On Tue, Oct 04, 2005 at 06:16:21PM +0200, Zeugswetter Andreas DAZ SD wrote: > > > Another possibility is optimizing for the special case of > > indexing on a partitioning key. In this case, index values > > would be very localized to one table, so just storing the > > table info on each index page (or something similar) would work well. > > If you have the partitioning key in the index and the partitions don't > overlap, it is better to create separate [unique] indexes on the > subtables. > Building separate indexes per partition is usually preferred because of: > 1. performance of dropping a partition > 2. smaller index for CE > > Only if you need an "order by" without a sort step, that spawns more > than one partition > things usually get ugly. Imho the best solution would be a merge node, > that merges results of > several index accesses to avoid a sort and still use separate indexes. > Such > a merge node could probably also detect the case where accessing > partitions in a certain > order still produces ordered results. > > Usually you will only want the "one big unique index" when the > partitioning is not > reflectable in the index keys, and then (also in other db's) such an > index is usually a pain ... > > Andreas > > ---------------------------(end of broadcast)--------------------------- > TIP 5: don't forget to increase your free space map settings > -- Jim C. Nasby, Sr. Engineering Consultant jnasby@pervasive.com Pervasive Software http://pervasive.com work: 512-231-6117 vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461
On Tue, 2005-10-04 at 18:16 +0200, Zeugswetter Andreas DAZ SD wrote: > > Another possibility is optimizing for the special case of > > indexing on a partitioning key. In this case, index values > > would be very localized to one table, so just storing the > > table info on each index page (or something similar) would work well. > > If you have the partitioning key in the index and the partitions don't > overlap, it is better to create separate [unique] indexes on the > subtables. > Building separate indexes per partition is usually preferred because of: > 1. performance of dropping a partition > 2. smaller index for CE ... > Imho the best solution would be a merge node, > that merges results of > several index accesses to avoid a sort and still use separate indexes. > Such > a merge node could probably also detect the case where accessing > partitions in a certain > order still produces ordered results. Yes, that was my conclusion also. There are a number of intermediate steps along the way, so it will take some time to achieve it. > Usually you will only want the "one big unique index" when the > partitioning is not > reflectable in the index keys, and then (also in other db's) such an > index is usually a pain ... Agreed^2. The idea of a global index is a non-starter for all of the reasons that Tom gave and the main one: Its's unusably huge. There's no point in partitioning a 1TB table if you then have to build a 500GB index on it. The tree would be so deep that each insert would require maybe 3 I/Os on index branch blocks before you got to the leaf. Insert performance would suck real bad, which is a blocker since if you have a large table you almost certainly have a lot of data to load. If you don't have a big table you shouldn't be partitioning it anyway. Best Regards, Simon Riggs
On Tuesday 2005-10-04 13:54, Simon Riggs wrote: > On Tue, 2005-10-04 at 18:16 +0200, Zeugswetter Andreas DAZ SD wrote: > > > Another possibility is optimizing for the special case of > > > indexing on a partitioning key. In this case, index values > > > would be very localized to one table, so just storing the > > > table info on each index page (or something similar) would work well. > > > > If you have the partitioning key in the index and the partitions don't > > overlap, it is better to create separate [unique] indexes on the > > subtables. > > Building separate indexes per partition is usually preferred because of: > > 1. performance of dropping a partition > > 2. smaller index for CE > > ... <snip> merge node strategy. </snip> > > Usually you will only want the "one big unique index" when the > > partitioning is not > > reflectable in the index keys, and then (also in other db's) such an > > index is usually a pain ... > > Agreed^2. The idea of a global index is a non-starter for all of the > reasons that Tom gave and the main one: Its's unusably huge. There's no > point in partitioning a 1TB table if you then have to build a 500GB > index on it. The tree would be so deep that each insert would require > maybe 3 I/Os on index branch blocks before you got to the leaf. Insert > performance would suck real bad, which is a blocker since if you have a > large table you almost certainly have a lot of data to load. If you > don't have a big table you shouldn't be partitioning it anyway. It has taken me a while to organize my thoughts on this post to the thread, but I am struck by the fact that what started out as a discussion of relational inheritance and support for multi-relation uniqueness by indexes morphed into a discussion of partitioning table storage and how that might be supported by indexes. It is possible that the topical change was simply due to the usual meandering of threads but I fear that instead it may not have been random but caused by conflating the inheritance problem with partitioning. The two problems have seeming similarities inasmuch as both involve multiple internal tables. Unfortunately, they are rather distinct. Partitioning is a database engineering tool to enhance the performance of HUGE databases, most notably biogenetic databases. Partitioning is a classic divide and conquer strategy -- the goal is to chop something unmanageably large into things that are manageably small. Just as critical partitioning is in no way a relational problem. It has no effect on data representation and it should be irrelevant to a database developer or a report writer. Partitioning is strictly a storage and implementation problem. In general, one partitions by a hash rule (usually a simple modulus operation on a serial number or OID) or by a range rule -- typically on a date-time or possibly postal codes. Since the partition rule is "published" the database engine can "hash" to the proper index or table. Note that just as one can have multi-dimensional arrays, partitioning presents an analogous data storage problem and there is no logical reason that a relation could not be partitioned by any number of ranges or hashes. In practice, this serves no useful performance advantage, but simply divides the logical table (relation) into many small physical tables. In Oracle indexes of attributes that are used as partitioning criteria are simply partitioned in parallel to the (logical) table they reference. This seems to be the sort of solution that the thread was heading toward. --- In contrast relational inheritance is a design tool that would allow polymorphic access to modestly large relations. Note that an instance of relational inheritance explicitly or implicitly establishes a relational class. Furtheremore, a relational class is a type of multi-relation. Relational inheritance provides partial semantic unification over a taxonomic space. The semantic element in relational inheritance is critical. With a relation partitioned on _sequence_result_, given any _sequence_result_ one knows in what physical table(s) to look up the associated tuple (because by definition partitioned relations have partition rules). With a multi-relation partially unified on _sequence_result_, however, there is no way one can know what member table has _sequence_result_'s tuple. In the case of a relational class (or any other partially unified multi-relation) you have to use a layer of indirection. Class-wide uniqueness (partial unification of multi-relations) can be solved by using a global index for the relational class. It cannot be solved using partitioning. In many ways the problems are quite distinct. ===== Of course, there is no reason a relation in a relational class might not be huge. By way of inclusion, a relational class containing one or more huge relations would also be huge. It seems to me that rather that partitioning member relations on unifying attribute(s), implementation would be easier if one were required to partition entire semi-unified multi-relations as a whole. Orthoganal partion rules would be created for the class. The rules would be applied to each member relation. Finally, the rules would be applied to the relevant unifying (presumably unique) indexes. But inasmuch as Postgresql has implemented neither partitioning nor unique constraints for relational classes we are getting somewhat ahead of ourselves. ==== Partitioning is obviously dominated by partitioning rules. Oracle's SQL dialect provides a negative example of how to elegantly incorporate partitioning rules into SQL. Ideally partitioning rules should be first-class objects. A database engineer or the poor DBA who inherits his implementation should be able to query the meta-data to get a listing of all partitioned relations.
On Mon, 2005-10-10 at 19:58 -0700, Trent Shipley wrote: > Of course, there is no reason a relation in a relational class might not be > huge. Well, as a designer, I would make it so. > Orthoganal partion rules would be created for the class. The rules would be > applied to each member relation. Finally, the rules would be applied to the > relevant unifying (presumably unique) indexes. > > But inasmuch as Postgresql has implemented neither partitioning nor unique > constraints for relational classes we are getting somewhat ahead of > ourselves. Maybe you aren't aware of the new constraint_exclusion feature in 8.1 ? > Partitioning is obviously dominated by partitioning rules. Oracle's SQL > dialect provides a negative example of how to elegantly incorporate > partitioning rules into SQL. Ideally partitioning rules should be > first-class objects. A database engineer or the poor DBA who inherits his > implementation should be able to query the meta-data to get a listing of all > partitioned relations. The partitioning doesn't follow Oracle syntax at all. Partitions are first class objects as you suggest. Best Regards, Simon Riggs