Re: Idea for pear sequence tables

On Tuesday, September 16, 2003 13:44, Rob Hutton wrote: > Yes, this is true that there will be lock contention, but there would be > lock contention to a certain extent on a "sequence" table also. The > smallest piece that mosts DBs can lock for a write is a single block, which > in small tables like this, most likely contains more that one row, maybe > even the whole table. When something was committed to disk, then the whole > block again has to be locked (although pre and post imaging hide this > somewhat). > That said, it does not change the fact that I agree that it would be better > to put all of the sequences in one table. There are many situations where > unique ids per table, or at least in some tables, is a requirement. In most > cases it is desired per table simply so the sequences are reasonable. > The only reason that I can see to leave them in a separate table is the > perception that it is faster. The reason that I say perception is that in a > small table like this, I would bet that the access time is miniscule whether > you are reading two dozen records, or one. > The down side of them being in separate tables is that you have two dozen > separate tables junking up the schema. This is not a trivial thing. > So, why would a "single" sequence table not be done? Hearing the reasons, looks as a good idea. For the moment there are other areas which needs more attention, so I'm not going to put efforts on this in a near future. If you can provide tested patches for the most important drivers and think on a compat method for avoiding the break of the current behaviour, I'd be positive to commit it. -- Tomas V.V.Cox mailto:cox@idecnet.com