Hannu,
> If you don't get it, contact me as there is a small possibility that I
> know a company interested enough to fund (some) of it :)
Enough people have been interested in this that if we get our acts together,
we may do it as multi-funded. Easier on our budget ...
> As these are already discussed in this thread, I'll try to outline a
> method of providing a global index (unique or not) in a way that will
> still make it possible to quickly remove (and not-quite-so-quickly add)
> a partition.
<snip>
> To repeat - the global index over partitioned table should have te same
> structure as our current b-tree index, only with added map of 128k index
> partitions to 1G subfiles of (possibly different) tables. This map will
> be quite small - for 1Tb of data it will be only 1k entries - this will
> fit in cache on all modern processors and thus should add only tiny
> slowdown from current direct tid.page/128k method
I think this is a cool idea. It would need to be linked to clustering, so
that each partition can be an iteration of the clustered index instead of a
specifc # of bytes. But it would give us the "fully automated partitioning"
which is one fork of the two we want.
Plus I'm keen on any idea that presents an alternative to aping Oracle.
How difficult would your proposal be to code?
--
Josh Berkus
Aglio Database Solutions
San Francisco
