On Fri, 2008-01-04 at 13:06 +0530, Gokulakannan Somasundaram wrote: > a) This proposal would work for the kind of table organizations which > are currently partitioned and maintained based on some kind of > timestamp. Consider one of the use-case. A large Retail firm has a lot > of stores. DBA maintains and updates the inventories of those stores > in hash-partitions based on store-no. As the inventory gets updated, > the corresponding partition receives the update and it goes like > that.. > Here all the partitions are going to get constantly updated. > So no partition can possibly become a read only partition. You have > clearly called it out in your para. i am just re-confirming on that. > Or do you have something for this in your soln.? > > To my limited experience, most partition strategies are based on some > form of time-stamp. If the proposed soln. can cater to those, it has > lot of use-cases.
I don't think it would apply to an Inventory table. That is a current state table. It is designed for any large tables that would grow naturally over time if we left them to do so. Solutions that it would work for: - any Fact table where measurements/observations/events are accumulated e.g. Web Hits (any Internet events) Call Detail Records Sales Security Events Scientific Measurements Process Control - any Major Entity where new entities are created from a sequence e.g. Orders, OrderItems Invoices Shipments, Returns most SCM/DCM events It's not aimed at any particular benchmark, just real usage scenarios. -- Simon Riggs 2ndQuadrant http://www.2ndQuadrant.com ---------------------------(end of broadcast)--------------------------- TIP 2: Don't 'kill -9' the postmaster
